About this list Date view Thread view Subject view Author view Attachment view

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.


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

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 12 Nov 2003 - 00:21:37 GMT by hypermail 2.1.3