linux-kernel - Re: [PATCH 3/4] security: capabilities patch (version 0.4.4), part 3/4: introduce new capabilities

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: <450451DB.5040104@gentoo.org>
Date:	Sun, 10 Sep 2006 13:56:43 -0400
From:	Joshua Brindle <method@...too.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	David Madore <david.madore@....fr>,
	Linux Kernel mailing-list <linux-kernel@...r.kernel.org>,
	LSM mailing-list <linux-security-module@...r.kernel.org>
Subject: Re: [PATCH 3/4] security: capabilities patch (version 0.4.4), part
 3/4: introduce new capabilities

Alan Cox wrote:
> Ar Sul, 2006-09-10 am 15:42 +0200, ysgrifennodd David Madore:
>   
>> Introduce six new "regular" (=on-by-default) capabilities:
>>
>>  * CAP_REG_FORK, CAP_REG_OPEN, CAP_REG_EXEC allow access to the
>>    fork(), open() and exec() syscalls,
>>     
>
> CAP_REG_EXEC seems meaningless, I can do the same with mmap by hand for
> most types of binary execution except setuid (which is separate it
> seems)
>
> Given the capability model is accepted as inferior to things like
> SELinux policies why do we actually want to fix this anyway. It's
> unfortunate we can't discard the existing capabilities model (which has
> flaws) as well really.
>
>   
To expand on this a little, some of the capabilities you are looking to 
add are of very little if any use without being able to specify objects. 
For example, CAP_REG_OPEN is whether the process can open any file 
instead of specific ones. How many applications open no files whatsoever 
in practice? Even if there are some as soon as they change and need to 
open a file they'll need this capability and will be able to open any. 
CAP_REG_WRITE has the same problem. For a description of why 
CAP_REG_EXEC is meaningless see the digsig thread on the LSM list from 
earlier this year.

Further, adding more capabilities would likely make existing LSM's (like 
SELinux) deal with them. Since most LSM's already handle these 
permissions on a per-object basis these will be entirely redundant and 
more disruptive than useful.

Additionally since dropping capabilities is entirely discretionary and 
applications would be modified to actually drop the capabilities I can't 
ever see this being used in practice. It also embeds the policy into 
applications spread across the filesystem instead of having a 
centralized policy.  Since these are non-standard capabilities any 
application modified to take advantage of them could only do so on Linux.
-
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/