l i n u x - u s e r s - g r o u p - o f - d a v i s
L U G O D
 
Next Meeting:
October 7: Social gathering
Next Installfest:
TBD
Latest News:
Aug. 18: Discounts to "Velocity" in NY; come to tonight's "Photography" talk
Page last updated:
2002 Jun 12 14:47

The following is an archive of a post made to our 'vox mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox] Who opened the floodgates?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox] Who opened the floodgates?



Rick Moen writes:
 > Quoting Micah Cowan (micah@cowan.name):
 > 
 > > Sorry, Pete, but I don't think this cuts it. Think how many times
 > > people have been compromised over Sendmail or BIND regardless of how
 > > much attention they pay to those three points.
 > 
 > Let's think about that.
 > 
 > 1. Sendmail.  In the bad old days, sendmail was not only an enormous,
 > SUID-root binary, but always carried around root authority with it, 
 > regardless of what role the binary instance was serving.  That practice 
 > was ended some while ago.   In recent versions, although the binary is
 > still set SUID root, instances of it in RAM drop privilege according to
 > the role they serve, just after being spawned.
 > 
 > Since then, the codebase's security history has been generally pretty 
 > good.  Postfix has what is in theory a somewhat sounder architecture,
 > being fully modular.  However, you lose a little bit in complexity of 
 > interaction among the parts.
 > 
 > 2.  BIND _was_ a problem because the 8.x codebase was hopeless spaghetti
 > code.  Everyone knew that, but the only possible fix (short of switching
 > to MaraDNS, etc.) was to commission a from-scratch rewrite to the
 > existing specs.  That's exactly what Paul Vixie / ISC did, and the
 > result is BIND 9.x -- which, again, has had a generally pretty good 
 > security history.

Very true. However, the principle is still the same - no program can
be 100% gauranteed safe code (especially, as in some unfortunate
circumstances, the fault was glibc's, and not the program proper), so
treat root privileges like burning hot metal.

 > > 4. Never run anything as root, unless absolutely necessary.
 > > 5. If you must run as root, get out of root-hood as absolutely soon as
 > > possible.
 > 
 > In practice, one of the best ways of making this happen is to use sudo
 > instead of su (for that purpose) -- if only because privilege times out
 > automatically.  It was part of my LinuxWorld lecture, last year.
 > Lecture notes here:  http://linuxmafia.com/lwce2001/

Right. Although sudo won't help the case where you're running a
single program for a lengthy period, which is what I was thinking of.

 > > 6. If as absolutely soon as possible isn't nearly immediate, or you
 > > must run as root for some time, be in a minimal, chrooted environment.
 > 
 > It should be noted that the root user can break out of any chroot
 > environment, pretty trivially.

Boy, that kinda defeats the purpose of chroot(), doesn't it?

I didn't know that - can you provide a brief explanation on how this
may be done, or pointers to more information?

-Micah
_______________________________________________
vox mailing list
vox@lists.lugod.org
http://lists.lugod.org/mailman/listinfo/vox



LinkedIn
LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
facebook
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Sunset Systems
Who graciously hosts our website & mailing lists!