On Saturday 14 January 2006 22:21, Olaf Dietsche wrote:
> This patch implements filesystem capabilities. It allows to run
> privileged executables without the need for suid root.
Why not implement this via xattr framework and the "system."
namespace there? I would suggest "system.posix_capabilties" for this.
That way you can reduce your infrastructure, take advantage
of caching features, have user space tools for viewing and changing
this and resize2fs works for it now or soon.
What do you think?
Regards
Ingo Oeser
>> This patch implements filesystem capabilities. It allows to run
>> privileged executables without the need for suid root.
>
>Why not implement this via xattr framework and the "system."
>namespace there? I would suggest "system.posix_capabilties" for this.
>
>That way you can reduce your infrastructure, take advantage
>of caching features, have user space tools for viewing and changing
>this and resize2fs works for it now or soon.
>
>What do you think?
I think some filesystems lack the luxury of xattrs.
Jan Engelhardt
--
Ingo Oeser <[email protected]> writes:
> On Saturday 14 January 2006 22:21, Olaf Dietsche wrote:
>> This patch implements filesystem capabilities. It allows to run
>> privileged executables without the need for suid root.
>
> Why not implement this via xattr framework and the "system."
> namespace there? I would suggest "system.posix_capabilties" for this.
This already exists. See
<http://groups.google.com/group/linux.kernel/browse_frm/thread/bbcb9a5d4204db6d/92da59d319865d7b>,
<http://groups.google.com/group/linux.kernel/browse_frm/thread/b8f2508c00c76938/d76a17c820b8a0a8>
and <http://www.stanford.edu/~luto/linux-fscap/>
> That way you can reduce your infrastructure, take advantage
> of caching features, have user space tools for viewing and changing
> this and resize2fs works for it now or soon.
>
> What do you think?
Short (and lazy ;-) answer: <http://groups.google.com/group/linux.kernel/browse_frm/thread/6a4f4b26c110c742/83ad1d63035fd290>
Regards, Olaf.
Olaf Dietsche <[email protected]> wrote:
> This patch implements filesystem capabilities. It allows to run
> privileged executables without the need for suid root.
>
> Changes:
> - updated to 2.6.15
>
> This patch is available at:
> <http://www.olafdietsche.de/linux/capability/>
>
> Regards, Olaf.
>
> diff -urN a/fs/Kconfig b/fs/Kconfig
> --- a/fs/Kconfig Wed Jan 4 22:01:06 2006
> +++ b/fs/Kconfig Sun Jan 8 15:12:25 2006
> @@ -1209,6 +1209,69 @@
> It's currently broken, so for now:
> answer N.
>
> +config FS_CAPABILITIES
> + bool "Filesystem capabilities (Experimental)"
> + depends on EXPERIMENTAL
> + default n
> + help
> + This implementation is likely _not_ POSIX compatible.
> +
> + If you say Y here, you will be able to grant selective privileges to
> + executables on a needed basis. This means for some executables, there
> + is no need anymore to run as root or as a suid root binary.
> +
> + For example, you may drop the SUID bit from ping and grant the
> + CAP_NET_RAW capability:
> + # chmod u-s /bin/ping
> + # chcap cap_net_raw=ep /bin/ping
Why the cap_ part? It should be enough to say, e.g.
chcap net-raw=ep /bin/ping
('_' has SHIFT, normally... '-' is easier to type)
> +
> + Another use would be to run system daemons with their own uid:
> + # chcap cap_net_bind_service=ei /usr/sbin/named
> + This sets the effective and inheritable capabilities of named.
> +
> + In your startup script:
> + inhcaps cap_net_bind_service=i bind:bind /usr/sbin/named
AFAIU, the =i implies inherited, why another command to set that?
Can't comment on the rest.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Sorry for the late response, I've been away for the week.
Horst von Brand <[email protected]> writes:
> Olaf Dietsche <[email protected]> wrote:
>> + For example, you may drop the SUID bit from ping and grant the
>> + CAP_NET_RAW capability:
>> + # chmod u-s /bin/ping
>> + # chcap cap_net_raw=ep /bin/ping
>
> Why the cap_ part? It should be enough to say, e.g.
>
> chcap net-raw=ep /bin/ping
>
> ('_' has SHIFT, normally... '-' is easier to type)
This is the way libcap expects the capabilities string. I never
questioned the format of this string. But it isn't hard to do a simple
mapping.
>> +
>> + Another use would be to run system daemons with their own uid:
>> + # chcap cap_net_bind_service=ei /usr/sbin/named
>> + This sets the effective and inheritable capabilities of named.
>> +
>> + In your startup script:
>> + inhcaps cap_net_bind_service=i bind:bind /usr/sbin/named
>
> AFAIU, the =i implies inherited, why another command to set that?
Look for keep_capabilities in security/commoncap.c. If you do a
setuid() away from root, Linux drops all privileges. Inhcaps does a
setuid() and arranges for keeping the needed capabilities.
Regards, Olaf.