Re: patch to make Linux capabilities into something useful (v 0.3.1)

On Wed, Sep 06, 2006 at 12:27:50AM +0000, Casey Schaufler wrote:
--- David Madore <david.madore@xxxxxx> wrote:
As we all know, capabilities under Linux are
currently crippled to the
point of being useless.

The current work in progress to support
capability set on files will address this
longstanding issue.

It seems to me that the issues of the capability inheritance semantics
and the capability filesystem support are quite orthogonal. My patch
provides the first, and will quite happily live with a patch such as
<URL: http://lwn.net/Articles/142507/ > providing filesystem support.

Even in the absence of filesystem support, there is no reason for
capabilities not to be inheritable: this is what my patch addresses.
Of course, it is even more interesting in the presence of filesystem
support. (I could provide a combined patch that would do both, with
xattrs, as a proof of concept.)

Not a bad idea, but the notion of underprivileged
processes has been tried before. The capability
mechanism is explicitly designed to provide for
the seperation and management of privilege and
taking it in the "other" direction requires
a rethinking of the inheritance mechanism.

Yes, it required a slight rethinking, and that is precisely what I am
providing: <URL: http://www.madore.org/~david/linux/newcaps/#semantics >.
Do you see anything specificly wrong with it?

In short: currently (i.e., prior to applying this
patch), Linux has
capabilities, but they are (deliberately) crippled,

The crippling is not deliberate.

At least the crippling of CAP_SETPCAP was deliberate and unnecessary:
it was done following an incorrect analysis by the sendmail team of a
caps-related sendmail exploit under Linux.

It is
unfortunate and represents a number of complex
issues that are being resolved. Finally.

Resolving them is precisely what I proposed to do. If you are saying
someone else also proposed to do the same, can you point to that work?
Perhaps we could merge usefully and thus go forward faster.

Again, the capability scheme is intended to
address the omnipotent userid problem. It pulls
the userid and privilege apart. It also provides
a more granular privilege. But it does not change
what operations require privilege. That is left
to wiser minds.

I don't quite understand what you're saying here. Do you see
something wrong with my proposal for doing it?

--
David A. Madore
(david.madore@xxxxxx,
http://www.madore.org/~david/ )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: Decision To Go To War
    ... did not support the war. ... I did not believe that the weapons were the issue, ... And if Saddam really wanted to have such a capability, ...
    (soc.retirement)
  • Re: [2.6 patch] remove securebits
    ... Attached is what I consider only an RFC patch. ... In the absence of filesystem capability support, ... int (int option, unsigned long arg2, ... int security_task_prctl(int option, unsigned long arg2, unsigned long arg3, ...
    (Linux-Kernel)
  • Re: [2.6 patch] remove securebits
    ... Attached is what I consider only an RFC patch. ... In the absence of filesystem capability support, ... -/* Transfer any capability in your permitted set to any pid, ... int (int option, unsigned long arg2, ...
    (Linux-Kernel)
  • Re: Decision To Go To War
    ... As far as your argument is concerned, I find it quite ludicrous that you argue to support decisions based on ignorance and ideology rather than on evidence. ... To listen to the arguments to justify going to war, and to listen to the arguments that say we should not go to war. ... I did not believe that the weapons were the issue, but what they would do with the weapons that was the issue. ... And if Saddam really wanted to have such a capability, he would get the capability, it would just be a matter of time. ...
    (soc.retirement)
  • ANN: eric 4.2.0 released
    ... added API file for Ruby ... added Ruby API file for eric4 Ruby files ... added capability to save the folding state of a file in the session ... added HTTPS support to plugin repository dialog ...
    (comp.lang.python)