Re: filesystem access security

[James Buchanan]

This seems like a good idea, but why should it be necessary to examine
the trusted status of users' translators when a user wouldn't normally
have write access to the root filesystem?

Shouldn't it be the case that system translators affecting critical
things system-wide have a set of capabilities, so only root can give a
user the ability to set a translator for the root filesystem?  Perhaps
this should apply for the root filesystem, all devices attached to the
system and /etc configuration files and directories, because these
affect all users on the system.  Maybe it should extend to object file
interpreter/loader translators too, etc.  Users should by default only
have the ability to set translators affecting themselves, i.e. that
localised part of the system, such as /usr/login/.

But otherwise, having further checks by glibc on top of those that the
HURD might make itself seems like a good idea.  While giving users as
much freedom as possible is wonderful, it doesn't make a lot of sense to
give them the ability to set a translator for critical system parts that
affect everyone in the multiuser environment, does it?

                                James


--- From Marcus on hurd-devel ---

Hi,

when I was in Karlsruhe to meet some other guys, Wolfgang (I think) had
the following idea about improving the security of the filesystem access
in the Hurd.  The test case is a firmlink to / in /tmp, created by a
malicious user, and "rm -fR /tmp/*".  Of course, we have a special
routine in our boot script to clean tmp, but are we going to rewrite
Unix system administration manuals?  Are we going to fix all scripts
which access user's home directories for writing, starting from deluser?

There is something inherently suspicious about accessing other,
untrusted people's filesystems.  And we better have a way to make it
possible to ensure that it is not going to happen.

So, the idea was that you can specify the list of users you trust.  By
default, this would be root, and yourself.  Maybe a special range of
user ids that are "system users" (1-9999 on Debian, for example).  You
can grant/restrict access by setting an environment variable, and glibc
will then use this list of users to check if a translated should be
looked up resolving the translator, or ignoring it.  The idea is that if
root uses the default setting, he will not see any user's translators
transparently, and rm -fR can never harm him.

Other users who cooperate can trust each other, and see each others
translators.  A similar feature could be provided for groups, and
appropriate rules defined.

This requires that glibc always does a secure lookup, and then inspects
the node to decide if it wants to resolve the translator or not.  This
adds a small cost to all cross-translator lookups, but cross-translator
lookups are expensive already anyway.

I think this is a critical security feature for a real world multi-user
environment.  If you have comments, ideas, etc, I would appreciate to
hear about it.

Thanks,
Marcus


-- 
`Rhubarb is no Egyptian god.' GNU      http://www.gnu.org   
marcus@bogus.example.com
Marcus Brinkmann              The Hurd http://www.gnu.org/software/hurd/
Marcus.Brinkmann@bogus.example.com
http://www.marcus-brinkmann.de/