[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFD: new section ("secure"?)

On Tue, Jan 18, 2000 at 06:25:42PM -0700, Bear Giles wrote:
> > On Sun, Jan 16, 2000 at 10:51:20AM -0700, Bear Giles wrote:
> > >  - all packages listed above, or added to the "secure" section later,
> > >    will have "Provides:" and "Replaces:" fields to allow a secure 
> > >    alternative to replace them without causing dependency problems
> > >    or arcane version information.  In this case, the secure package
> > >    should have a unique name, e.g., "cvs" becomes "kcvs", "lprng"
> > >    becomes "klprng."
> > 
> > would this also include more secure/paranoid base/commonly used packages?
> Due to the risk of exponential forking, I would suggest that the
> (top-level) "secure" section only have new packages if the *binaries*
> have changed, e.g., due to linkage against additional libraries which
> are present in "secure."  In most cases, the user should install the
> package then install the secure-ifying package on top of it.  The classic
> example is netscape & fortify.
> > removal of the non-essential suid bits on stuff like mount and chrooting bind
> > are some of the first things i do to machines although i do suppose these
> > minor tweaks could be handled as a low priority option in debconf.
> That's what makes this change so necessary, IMHO.  Of course anyone could
> write a 'main' package that adds
>    /etc/crontab.daily/strip-setuid
>       mount /home -oremount,nodev,nosuid
> 	  find /home -perm +4000  -exec chmod ug-s {} \;
> 	  find /usr -perm +4000 -exec chmod ug-s {} \;
> 	  # restore the trusted files
> 	  chmod u+s /bin/login
> 	  ....
> But that package would get lost in 'main.'  It doesn't belong in base,
> but do you put it into admin?  utils?  In general, where do the
> security enhancing packages go?  (Hint: it's easier to list where these
> packages haven't shown up yet. :-)
> Pulling everything into a new section which is recognized, but not
> officially part of Debian until woody, will give everyone a chance to
> figure out what a basic "secure Debian" system should look like... and
> a much cleaner target for us raving paranoids to work against.

i think having a package semi-haphazardly changing permissions of binaries
owned by other packages is a bad idea. it could potentially break the box of a
newbie-type who accidentally installs such package.

perhaps a more viable solution would be a debconf systemwide security level
default. for example, i realize that having a nonsuid mount binary is not
expected, yet i favor disregarding that in favor of security.
> > also, i don't see anything about chroot jails in the FHS or the policy, do we
> > have anything on record about this?
> I've been doing a lot of research into chroot jails recently, and all
> I can say is that they make life interesting.  E.g., lprng needs ghostscript
> inside of its sandbox, but should ghostscript always be in a sandbox of its
> own?  (Ghostscript is a Turing-equivalent language and *could* be used to
> read or overwrite any file readable by the calling process.)  I'm leaning
> towards "yes" -- but does that mean I need nested sandboxes?
> Back to the question, AFAIK "/usr/local" is against policy, they don't 
> fit into /usr/share because they may have dynamic local content and spools, 
> and they don't fit into /var since they have a lot of static binaries and
> libraries.
> So I've been punting and putting them into /opt/sandboxes, with the
> intent to add symlinks from /var into /opt/sandboxes/appl/var later.
> ("Sandboxes" because I refer to the entire mess as an "application
> sandbox", not a chroot jail, since many people are more familiar with
> Java sandboxes than chroot.)  But my work is unabashedly third-party
> so there's no problem with using /opt - the situation would be very
> different if the default installation used a sandbox/chroot jail.
> (P.S., anyone who wants to know what sandboxes I have set up should
> contact me.  Some of them have surprising problems, due to the assumption
> of a Unix socket in /tmp or the syslog /dev/log.  I have some ideas on
> a solution, but haven't implemented the kernel modules yet.)

there's an option in newer sysklogd's to listen on more than /dev/log.
nathan a ferch
"I just realized something.  We've never had a completely successful test with any of the equipment." -Stantz

Reply to: