From: Linas Vepstas (linas_at_linas.org)
Date: Wed 12 Nov 2003 - 00:21:04 GMT
On Tue, Nov 11, 2003 at 03:58:59PM -0800, Chris Wright was heard to remark:
> * Linas Vepstas (linas_at_linas.org) wrote:
> >
> > Why is the libcap mailing list so quiet? Why does google not find
> > anything interesting for Linux capabilities? Is this because there
> > is some deep-rooted, fundamental design-flaw or problem with
> > capabilities and/or with thier Linux implementation? Have the basic
> > libcap tools been obsoleted by selinux, rsbac or some other security
> > system? Or is it simply that "capability" is such a generic term that
> > newcomers don't bother to even invsetigate this technology?
> > I'm trying to understand why Linux capabilites is such a 'sleepy' topic.
>
> Linux capabilities is a reasonbly seasoned project, that's reached a
> similarly reasonable maturity state. There's not a lot of new
> development in the area, as what is done is largely a completion of the
> relevant bits of the withdrawn Posix.1e draft.
Yeah, well, isn't 'maturity' a synonym for 'almost dead'?
I don't buy your answer that "its more or less done" since there are
obvious gaping holes, and its not done at all:
-- there are no reasonable man pages for getpcaps,
-- there's also no project web page.
-- There's no 'howto',
I can gaurentee there there is no (and will be no) widespread adoption
by users/sysadmins unless there's a HOWTO, no active mailing list, and
decent man pages.
> Notably absent are the
> filesystem capabilities bits, see lkml for the many reasons that this is
> not popular.
investigating ...
> > Then a specific question:
> >
> > I started looking at capabilites so that I could remove some capabilities
> > from a process after its been started. For example: named/bind9: let
> > it start, let it chroot itself into place, then remove choot privledges
> > from it. I discovered that I can't do that because I don't seem to have
> > setpcap permissions ... appearently because its dangerous to have this.
> >
> > So the questions are:
> > -- Did I misunderstand something in explaining the above?
> > -- Is it 'fundamentally dangerous' to be able to take away caps from
> > other processes? It seems 'safe' to me, or at least no more dangerous
> > than having a root user who can kill -9 assorted processes ...
>
> SETPCAP means you can not only lower but raise privs of process other
> than yourself. It's a dangerious capability to give out.
Well, yes, that was my point. I'm getting the feeling that its implemented
incorrectly, that there should have been a pair of bits: LOWERPCAP and
RAISEPCAP, instead of SETPCAP. Seems to me that LOWERPCAP, by allowing
one process to take away the caps of another, is reasonably safe
and useful. So I was trying ask if you/other gurus see something flawed
with this line of reasoning.
--linas
-- pub 1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas_at_linas.org> PGP Key fingerprint = 8305 2521 6000 0B5E 8984 3F54 64A9 9A82 0104 5933 _______________________________________________ Vserver mailing list Vserver_at_list.linux-vserver.org http://list.linux-vserver.org/mailman/listinfo/vserver