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
nf@marginal.net
"I just realized something. We've never had a completely successful test with any of the equipment." -Stantz
Reply to: