This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: obtaining gcc3.0.1


>-----Original Message-----
>From: Peter Barada [mailto:pbarada@mail.wm.sps.mot.com]
>Sent: 23 August 2001 17:23

>Wow, sounds like someone didn't get their frosted flakes and caffeine
>this morning :-) 

  Heh, nahh, I'm just naturally sarcastic.  Since this is going well O-T,
and since Andy's problem is fixed and he probably isn't interested, I've
sent this one to the list only; if you want to talk further on the topic,
we should take it to private mail.

>'Refusing to allow an outgoing connection from one well defined
>machine to one well defined remote server on one specific port
>suggests ...' may be fine if you're in a company that has only 5
>employees, but if you work for a larger comanpy(like) mine, it is
>impossible to arrange a special connection, because if every one of
>the 40000+ engineers whine to the sysadmins that they need a specific
>port connection, the whole request system collapses and the network
>becomes impossible to administer.

  Your suggestion that a request to a network admin to provide network
facilities, required by a user who needs them to perform his job and who
presumably works for the same firm that actually owns the hardware that
constitutes the network and that only bought all that hardware in order to
provide tools for their employees to do their jobs more effectively with,
constitutes "whining" makes me wonder whether the network exists to serve
the users, or the users exist to serve the network.  If we can't have the
tools to do our jobs with because they are regarded as too dangerous, we
might as well all go home.

  Oh, and just how likely do you think that example is anyway?  Can you
name 40,000 protocols that an engineer could legitimately need to use in
their work ?  That's 1/3rd of all the ports there could possibly be.

  If every one of those 40,000 engineers was to make requests for outgoing
ports to be opened, odds are that almost all of them would be to one of just
a few protocols.  In fact, CVS is probably the only one that would crop up
more than once or twice.  It's a *very* poor sysadmin who blames his users
for the failings of his network management and administration systems.
Might I suggest that with a very few shell scripts and mail aliases on a 
*nix system, adding and subtracting users from groups authorised to make 
some outgoing connections could be pretty much automated, requiring the
admin only to make a policy decision the first time a user requests a new
port to be opened ?

>When the network is that large, you have no choice but to take a seige
>mentaility where it is easier to throttle all outside traffic through
>a few machines and slam the doors on almost all the ports and enforce
>proxies for everything else.  That's nearly the only way that you can have
>a warm-n-fuzzy feeling about the security of your network.

  "A warm and fuzzy feeling" is not in any way synonymous with "secure".
If you want to be that secure, just unplug the routers and run an entirely
isolated network.  Adopting a siege mentality is a very poor alternative
to actually assessing the risks and benefits of various network services 
realistically.

>So don't berate sysadmins because in the very long run, they may
>even have your best interests at heart.

  So what do you reckon the security risks of opening an outgoing port 
constitute ?  AFAICS, there are three main ones to consider:  possibility
of corporate secrets leaking out (but then again, do you cryptanalyze all
the outgoing email?), possibility of internal network configuration info.
that would be useful to hackers leaking out, and possibility of an
internal user connecting to an evil remote site that sends them back a 
buffer overflow instead of valid CVS (in this particular case) data.

  The first is a social problem that simply cannot be addressed by a 
technological fix in the first place.  The second is more real, although
you'll probably have a 10.x.x.x or 192.168.80.x internal network with NAT
or SOCKS proxying through the firewall, so nothing but your firewall's IP
should be transmitted; and the third is very very unlikely to be the case
for the Gnu/Gcc CVS server.

  Security isn't just about locking everything down tight; it's about
evaluating risk.  Where's the risk in allowing outgoing CVS?


      DaveK
-- 
" So far, science's crowning achievement, the Atomic Bomb, has not even
been able to alleviate the misery and torture of endless centuries of
world poverty." - George Hammond, self-proclaimed discoverer of the 
scientific proof of god.


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]