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]

Date:	Sun, 17 Sep 2006 16:39:16 -0400
From:	Joshua Brindle <method@...too.org>
To:	Pavel Machek <pavel@....cz>
CC:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	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

Pavel Machek wrote:
> Hi!
>
>   
>>>> 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? 
>>     
>
> Filters, for example. gzip -9 - and such stuff does not need to open
> any files. These should be easy to lock down, and still very useful.
>
> More applications could be made lock-down-aware, and for example ask
> master daemon to open files for them over a (already opened) socket.
>
>   
Unlikely.. As Jan pointed out in the last thread anything that links 
against glibc does a dozen opens on invocation:
[jbrindle@...face ~]$ strace -eopen gzip -9 -   
open("/usr/lib64/fglrx/tls/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No 
such file or directory)
open("/usr/lib64/fglrx/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/lib64/fglrx/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/lib64/fglrx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/fglrx/tls/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No 
such file or directory)
open("/usr/lib/fglrx/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file 
or directory)
open("/usr/lib/fglrx/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such 
file or directory)
open("/usr/lib/fglrx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib64/libc.so.6", O_RDONLY)      = 3
gzip: compressed data not written to a terminal. Use -f to force 
compression.
For help, type: gzip -h
Process 17519 detached

this wouldn't be able to run if it couldn't open libc.so so you'd be 
limited to static binaries (with statically linked libs that don't do 
any open() calls) that don't do any kind of name resolution (ip, uid), 
have no config files, etc. very limited.. and my other point was that 
even if you did have said binary (the limitations make this very 
unlikely though) the binary could never be changed to open a file since 
it would then get all open access since capabilities are not fine grained.

The benefits of this are so minuscule and the cost is so high if you are 
ever to use it that it simply won't happen..

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