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

[Bear Giles <bear@coyotesong.com>]

> 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.
 
> 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.)

Bear Giles
bgiles@coyotesong.com