linux-kernel - Re: capabilities patch: trying a more "consensual" approach

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4506A522.90005@gentoo.org>
Date:	Tue, 12 Sep 2006 08:16:34 -0400
From:	Joshua Brindle <method@...too.org>
To:	David Madore <david.madore@....fr>
CC:	Linux Kernel mailing-list <linux-kernel@...r.kernel.org>,
	LSM mailing-list <linux-security-module@...r.kernel.org>
Subject: Re: capabilities patch: trying a more "consensual" approach

David Madore wrote:
> Hello again,
>
> Given the rather cold reception that my "capabilities" patch has met,
> it is obvious that it will never be accepted in any official kernel,
> so I am now abandoning it and will try to suggest a different approach
> that, in my opinion, isn't nearly as useful or expressive, but which
> should probably be much more acceptable to those who found fault with
> my previous patch, since it follows various suggestions which I
> received on the list.
>
> First, attempt to implement POSIX draft semantics for inheritance as
> closely as the current situation will allow.  (I think this is wrong,
> but many people seem to care, and POSIX semantics is still better than
> no semantics at all.)  Actual filesystem support can come later (Serge
> Hallyn has a patch for that), but in the meantime it would be useful
> to add some (per-filesystem) mount options to specify the default
> "inheritable" and "effective" capability sets.  In the absence of this
> mount option, the behavior would be entirely unchanged, so everyone
> should be happy.  With the mount options, capabilities will be
> somewhat inheritable (only "somewhat", though, because with the POSIX
> semantics, even with a default set, you can't force a non-caps-aware
> process to gain caps in such a way that it will pass it on to its
> children).
>
> Second, suppress the idea of "regular" capabilities, and implement
> them with Linux Security Module hooks (the module could be called,
> say, "cuppabilities").  This won't do as much, but we can probably
> still get a few things done that way.  Unfortunately, the
> cuppabilities won't (can't) follow the same inheritance rules as
> capabilities, and this might be a bit confusing.  But better than
> nothing.
>
> Is there some objection to this scheme?  I should start coding it in a
> couple of weeks.
>   
Do you have a practical use case for this? It still doesn't address the 
questionable capabilities or the fact that the policy is embedded in the 
processes all over the system and therefore there is no analyzable 
system policy.

-
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/