linux-kernel - 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-next>] [day] [month] [year] [list]

Date:	Mon, 11 Sep 2006 23:28:26 +0200
From:	David Madore <david.madore@....fr>
To:	Linux Kernel mailing-list <linux-kernel@...r.kernel.org>,
	LSM mailing-list <linux-security-module@...r.kernel.org>
Subject: capabilities patch: trying a more "consensual" approach

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.

Happy hacking,

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