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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20060906100610.GA16395@clipper.ens.fr>
Date:	Wed, 6 Sep 2006 12:06:10 +0200
From:	David Madore <david.madore@....fr>
To:	Linux Kernel mailing-list <linux-kernel@...r.kernel.org>
Subject: 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@....fr> 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@....fr,
     http://www.madore.org/~david/ )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/