[Top][All Lists]

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

Re: Many questions about translators

From: Carl Fredrik Hammar
Subject: Re: Many questions about translators
Date: Fri, 16 Apr 2010 11:52:04 +0200
User-agent: Mutt/1.5.20 (2009-06-14)


On Thu, Apr 15, 2010 at 10:47:49PM +0200, Patrik Olsson wrote:
> To design HPM (Hurd Package Manager) I need answers to the following
> questions (at least to begin with):
>      1. Is it possible for an unprivileged user to override the
>         translator of a node with another translator (at least, in their
>         own view)? Basically, the question is if users' private HPM
>         instances would also be able to have / as target when the system
>         already has an HPM instance at that target (and thus the
>         installed software would be from both the system HPM instance
>         and the personal HPM instance, with the latter having
>         priority). 

You can't set a new translator to / without affecting the whole
system, but you can chroot a user's login shell to another directory.
which effectively would override his view of /.  This directory could
be a union of the real / and the user's personal HPM (using unionfs,
unionmount, or perhaps functionality built into HPM itself).

You can even do this without mounting the new root on the global
filesystem by using settrans --chroot.

>      2. If yes on question 1, would this be insecure? For example, if
>         the user overrides a library used by a setuid program? (Then
>         again, if the program is running as e.g. root by setuid, it
>         wouldn't [at least shouldn't] see the files as the user does)

Actually, I'm not entirely sure.  I know that the setuid program gets
its credentials from the translator the executable is in, but I don't
remember how / is handled or if linking is handled specially (and I'm
too lazy to investigate further ATM).

But even if this is the case this would be exploitable as long as there
is a single non-statically linked binary in the system, so you can't
make it worse.  ;-)

>      3. Is it possible to have one translator working on two nodes at
>         the same time (where the nodes have different meaning)? HPM
>         needs to build one target directory (node one), and then have
>         the interface directory where the user can control the manager
>         (node two). 

Yes, a translator can attach itself to multiple nodes, but if a translator
takes an active role in attaching itself it cannot be set as a passive
(start on demand) translator.

Instead, you probably want some inferior translator that contacts a
master translator.  For instance, the interface directory could be a
separate translator that sends commands to the target directory translator
via some specialized interface.  This could also allow the user to have
several interface directories.

It is also possible to forward the actual startup request from the
interface translator to the target translator, which would then take
over the node, leaving you with a single running translator.  I'm not
sure I'd recommend this approach though.

>      4. Is it possible for a translator to provide different views of
>         the node for different users? For example, could each user have
>         their own list of packages they want installed and the HPM
>         translator would use ref-counting to install packages with
>         ref-count > 0, and/or perhaps even make different packages
>         appear installed for different users?

This is actually possible, as the translator knows the user of the
client so it can grant or withhold access.  But I suspect that using
it to provide different services to different users would violate many
assumptions made by clients.

I wouldn't object using this to provide something like `/dev/whoami'
which would contain the UID of the reading process, but I don't think
you should consider this possibility for HPM any further.  Just go with
different translators or nodes for different users.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]