[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: setuid vs. EROS constructor
From: |
Jonathan S. Shapiro |
Subject: |
Re: setuid vs. EROS constructor |
Date: |
Mon, 17 Oct 2005 08:53:19 -0400 |
On Mon, 2005-10-17 at 11:17 +0200, Bas Wijnen wrote:
> This doesn't seem to be true. I thought all capabilities would be enpoints,
> but (at least in EROS) they aren't. With the scheme I described here, it
> would not be possible to guarantee confinement of xmms, because it needs a
> high priority scheduling capability.
As long as this scheduling capability is authorized, it does not violate
confinement.
> If we don't want to give this capability
> to the user, xmms will be "setcapabilities" to achieve this, which will make
> the check fail.
Yes, although we can use the extended "authorized holes" check to let
this pass.
> For some reason I don't like the constructor approach though. I would prefer
> it if the default way of starting a new process would be to just do it
> directly. I don't really know why I prefer that, and it seems to prevent good
> things to happen. So it may not be a good idea.
I don't know how, in principle, to start a process more directly. What
the EROS constructor implements in this regard is simply "spawn". The
*ability* to run the confinement check is not an obligation to do so.
> Well, if you start your own child and don't give it any capabilities except
> ones pointing to yourself, you can also guarantee confinement of course. I
> would think that this should be possible in the majority of cases.
If you are doing this in POSIX, the answer is: no, you cannot. Every
POSIX process has access to a file system and the socket subsystem, both
of which allow it to extend its capabilities without any authorization
from the parent process.
> > Yes, the constructor has the ability to provide external capabilities.
> > In fact, it *has* to, because the initial address space capability for
> > the yield is an external capability.
>
> I think in the Hurd we would do this via a capability to the task server..
This would work functionally, but it would have a cost: you would no
longer be able to test confinement.
> > In practice, I think that in a real operating environment we would have
> > certain system directories where we would enforce some guarantees:
> >
> > 1. All items bound in these directories are constructors.
> > 2. All of these constructors certify that their yield is confined.
>
> This is just an optimisation, I suppose? This can be tested without any
> problem.
Yes. It is an optimization both in time and in mental concept space. It
allows the developer to say to themselves "okay, here is a pile of
known-safe reusable components".
> > A good example of where this is appropriate would be the equivalent
> > of /bin. The main reason to do it is that this entire directory can now
> > be handed to a hostile program (the directory must be read-only, of
> > course). The hostile sub-program can happily run any of these programs
> > that it chooses to run, because none of them extend the authority of the
> > sub-program in any way.
>
> That would be /bin with all setuid files removed :-)
Nah. We didn't support setuid anyway. As long as the bit doesn't *mean*
anything we might as well keep it for sentimental reasons. :-)
shap
- Re: setuid vs. EROS constructor, (continued)
- Re: setuid vs. EROS constructor, Bas Wijnen, 2005/10/24
- Re: setuid vs. EROS constructor, Jonathan S. Shapiro, 2005/10/24
- Re: setuid vs. EROS constructor, Bas Wijnen, 2005/10/25
- Re: setuid vs. EROS constructor, Jonathan S. Shapiro, 2005/10/25
- Re: setuid vs. EROS constructor, Bas Wijnen, 2005/10/25
- Re: setuid vs. EROS constructor, Jonathan S. Shapiro, 2005/10/25
- Re: setuid vs. EROS constructor, Bas Wijnen, 2005/10/25
- Re: setuid vs. EROS constructor, Jonathan S. Shapiro, 2005/10/25
- Re: setuid vs. EROS constructor, Jonathan S. Shapiro, 2005/10/13
- Re: setuid vs. EROS constructor, Bas Wijnen, 2005/10/17
- Re: setuid vs. EROS constructor,
Jonathan S. Shapiro <=
- Re: setuid vs. EROS constructor, Bas Wijnen, 2005/10/24
- Re: setuid vs. EROS constructor, Michal Suchanek, 2005/10/24
- Re: setuid vs. EROS constructor, Bas Wijnen, 2005/10/24
- Re: setuid vs. EROS constructor, Jonathan S. Shapiro, 2005/10/24