headers
Marcus Brinkmann | 12 Oct 2003 03:32
Picon
Favicon

future of libports

Hi,

I have some larger changes in mind for the libports replacement on L4
(libhurd-cap).  I want to share the fundamental consequences, and if
you can think of a situation where it would be too restrictive, please let
me know.  I checked the current code base, and it seems to be ok so far.
For the following, you can think of a capability as something equivalent to
a libports port object.

* While right now ports are inlined into objects like protids, I will
  inline objects into capabilities.  This way, objects will become part of
  the capality system, and several optimizations are possible.  For example,
  caching slab allocators are automatically used for such objects.  One
  consequence is that all objects that are related to each other (are in the
  same class) must have the same maximum size (you can use hook pointers of
  course).

* Of course, as Mach ports won't exist anymore, there are no ways to
  extract, insert, remove, or transfer port rights from or to capabilities.
  The capability itself is the only way to express something that resembles
  the current "receive right".  I checked the code carefully, and all cases
  where we currently use something like ports_transfer_right can be rewritten.
  Some functions will remain in different clothes.  For example,
  ports_reallocate_port really means: Revoke access to this object from all
  users, and that function can be implemented for capabilities as well.

* Buckets and classes will be merged into a single "class" object.
  There are many reasons and consequences, but the most convincing one is
  probably that we don't really treat them very independently in the Hurd
  code.  Often there is a 1-1 correspondence, in other cases several classes
(Continue reading)

Permalink | Reply | 0 comments |
headers
Marcus Brinkmann | 12 Oct 2003 15:33
Picon
Favicon

io_identity?

Hi,

I had another look at io_identity.  It seems to me to be a rather bogus
concept.  Why not just compare the fsid and inode number of the I/O object?
Sure, it's not always easy to make sure that those are unique (in
particular, the inode number) in all servers, but it's a nice and simple
concept.

Security can not be the reason.  What stops a malicious server from giving
out a send right to the I/O identity port of _another_ server.  This allows
any server to pretend to provide the same I/O object as any other server.
Is this intentional, or an oversight?

io_identity is not widely used.  It's used in fakeroot, and in getcwd.c of
glibc for canonicalization.  I am unsure about security implications in the
current implementation.  As long as you stay away from untrusted servers,
you are fine, if you use them, you are screwed anyway.

On L4, you always know who provides a given capability, as you know the
server thread ID implementing it.  So, you can do secure numerical
comparison.  If the purpose is to allow faking other I/O objects, then
using capabilities might be necessary (to ensure that there is always an
active reference to the I/O object - if an I/O identity port constitutes an
active reference.  However, the current implementation maps inode numbers to
I/O ports, so numerical comparison should be good enough).

Thanks,
Marcus

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcus Brinkmann | 12 Oct 2003 15:42
Picon
Favicon

filesystem access security

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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Roland McGrath | 12 Oct 2003 19:56

Re: io_identity?

It's really been a very long time since we were thinking hard about this.
Security was the reason I recall.  You at least can't fake the id of a node
you can't look up.  I agree that's not much of a guarantee to be worthwhile.
I have the sense I am forgetting something about the issue.
Permalink | Reply | 0 comments |

Gmane