file system capabilities

[Shridhar Daithankar-4]

Hi,

I was reading thr. /. commentary on the latest linux kernel bug, got drifted
into file system capabilities. and got this, (from
http://lwn.net/Articles/313838/)

[root@presario shridhar]# ls -la /bin/ping
-rwsr-xr-x 1 root root 33360 2008-10-04 17:48 /bin/ping
[root@presario shridhar]# chmod u-s /bin/ping
[root@presario shridhar]# setcap cap_net_raw=ep /bin/ping
[root@presario shridhar]# ls -al /bin/ping
-rwxr-xr-x 1 root root 33360 2008-10-04 17:48 /bin/ping
[root@presario shridhar]# exit
shridhar@presario ~$ ping 192.168.1.5
PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
64 bytes from 192.168.1.5: icmp_seq=1 ttl=64 time=0.219 ms
64 bytes from 192.168.1.5: icmp_seq=2 ttl=64 time=0.354 ms
^C
--- 192.168.1.5 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.219/0.286/0.354/0.069 ms

so can this be done by default? thus reducing setuid usage? it should improve
security right?

--
 Shridhar

[Daenyth Blank]

On Wed, Nov 4, 2009 at 10:12, Shridhar Daithankar
<ghodechhap@...> wrote:
> so can this be done by default? thus reducing setuid usage? it should improve
> security right?
>
This should probably go on the bug tracker as a feature request.

[Jan de Groot]

On Wed, 2009-11-04 at 20:42 +0530, Shridhar Daithankar wrote:

> Hi,
>
> I was reading thr. /. commentary on the latest linux kernel bug, got drifted
> into file system capabilities. and got this, (from
> http://lwn.net/Articles/313838/)
>
> [root@presario shridhar]# ls -la /bin/ping
> -rwsr-xr-x 1 root root 33360 2008-10-04 17:48 /bin/ping
> [root@presario shridhar]# chmod u-s /bin/ping
> [root@presario shridhar]# setcap cap_net_raw=ep /bin/ping
> [root@presario shridhar]# ls -al /bin/ping
> -rwxr-xr-x 1 root root 33360 2008-10-04 17:48 /bin/ping
> [root@presario shridhar]# exit
> shridhar@presario ~$ ping 192.168.1.5
> PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
> 64 bytes from 192.168.1.5: icmp_seq=1 ttl=64 time=0.219 ms
> 64 bytes from 192.168.1.5: icmp_seq=2 ttl=64 time=0.354 ms
> ^C
> --- 192.168.1.5 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 999ms
> rtt min/avg/max/mdev = 0.219/0.286/0.354/0.069 ms
>
> so can this be done by default? thus reducing setuid usage? it should improve
> security right?

This can be done by default, but capabilities aren't preserved when
making tarballs. Every capability has to be set from
post_install/post_upgrade in such cases. Maybe this is something worth
to implement though.

[Daenyth Blank]

On Wed, Nov 4, 2009 at 10:14, Daenyth Blank <daenyth+arch@...> wrote:
> On Wed, Nov 4, 2009 at 10:12, Shridhar Daithankar
> <ghodechhap@...> wrote:
>> so can this be done by default? thus reducing setuid usage? it should improve
>> security right?
>>
> This should probably go on the bug tracker as a feature request.
>

Actually, the article states that not all file systems support this,
so I don't think that it should be put in as the default. I think that
it deserves mention on the wiki, however.

[Gerardo Exequiel Pozzi-3]

Daenyth Blank wrote:

> On Wed, Nov 4, 2009 at 10:14, Daenyth Blank <daenyth+arch@...> wrote:
>  
>> On Wed, Nov 4, 2009 at 10:12, Shridhar Daithankar
>> <ghodechhap@...> wrote:
>>    
>>> so can this be done by default? thus reducing setuid usage? it should improve
>>> security right?
>>>
>>>      
>> This should probably go on the bug tracker as a feature request.
>>
>>    
>
> Actually, the article states that not all file systems support this,
> so I don't think that it should be put in as the default. I think that
> it deserves mention on the wiki, however.
>
>  

I writed an article in the wiki [#1] some time ago, for all common
setuids in core packages and xorg about this.
Some will fail and make more unsafe than safer (like mount)


[#1]
http://wiki.archlinux.org/index.php/Using_File_Capabilities_Instead_Of_Setuid

--
Gerardo Exequiel Pozzi ( djgera )
http://www.djgera.com.ar
KeyID: 0x1B8C330D
Key fingerprint = 0CAA D5D4 CD85 4434 A219  76ED 39AB 221B 1B8C 330D

[Magnus Therning]

On Wed, Nov 4, 2009 at 3:15 PM, Jan de Groot <jan@...> wrote:

> On Wed, 2009-11-04 at 20:42 +0530, Shridhar Daithankar wrote:
>> Hi,
>>
>> I was reading thr. /. commentary on the latest linux kernel bug, got drifted
>> into file system capabilities. and got this, (from
>> http://lwn.net/Articles/313838/)
>>
>> [root@presario shridhar]# ls -la /bin/ping
>> -rwsr-xr-x 1 root root 33360 2008-10-04 17:48 /bin/ping
>> [root@presario shridhar]# chmod u-s /bin/ping
>> [root@presario shridhar]# setcap cap_net_raw=ep /bin/ping
>> [root@presario shridhar]# ls -al /bin/ping
>> -rwxr-xr-x 1 root root 33360 2008-10-04 17:48 /bin/ping
>> [root@presario shridhar]# exit
>> shridhar@presario ~$ ping 192.168.1.5
>> PING 192.168.1.5 (192.168.1.5) 56(84) bytes of data.
>> 64 bytes from 192.168.1.5: icmp_seq=1 ttl=64 time=0.219 ms
>> 64 bytes from 192.168.1.5: icmp_seq=2 ttl=64 time=0.354 ms
>> ^C
>> --- 192.168.1.5 ping statistics ---
>> 2 packets transmitted, 2 received, 0% packet loss, time 999ms
>> rtt min/avg/max/mdev = 0.219/0.286/0.354/0.069 ms
>>
>> so can this be done by default? thus reducing setuid usage? it should improve
>> security right?
>
> This can be done by default, but capabilities aren't preserved when
> making tarballs. Every capability has to be set from
> post_install/post_upgrade in such cases. Maybe this is something worth
> to implement though.

Just in case someone knows, does star preserve capabilities, I'm under
the impression it does a better job on ACLs and other file system
flags than tar?

/M

--
Magnus Therning                        (OpenPGP: 0xAB4DFBA4)
[e-mail]          Jabber: [e-mail]
http://therning.org/magnus         identi.ca|twitter: magthe

[Thomas Bächler-2]

Jan de Groot schrieb:
> This can be done by default, but capabilities aren't preserved when
> making tarballs. Every capability has to be set from
> post_install/post_upgrade in such cases. Maybe this is something worth
> to implement though.

Actually, bsdtar preserves them when packing, but upon extracting they
are gone. I don't know if we can force pacman to make this work. Maybe,
maybe not.

On another note: This [1] is something about fs caps, but "part two"
didn't get finished, although it's November already. I have some code
written to work with capabilities more (capchroot, capsudo), you can
find the current status on http://projects.archlinux.org/. capchroot has
a crappy config parser, capsudo is better but suffers from some small
problems whose details I forgot. Both work though. I was going to
explain those tools on "part two", but as I said, I haven't written it yet.

[1]
http://archlinux.me/brain0/2009/07/28/using-posix-capabilities-in-linux-part-one/

[Xavier Chantry-2]

On Wed, Nov 4, 2009 at 4:39 PM, Magnus Therning <magnus@...> wrote:
>
> Just in case someone knows, does star preserve capabilities, I'm under
> the impression it does a better job on ACLs and other file system
> flags than tar?
>

After a bit of digging :

- Fedora and Redhat have a patched gnu tar with xattr support (which
should be similar to star according to [1])

- bsdtar has official xattr support. This works fine, except for the
special security.capability attribute, because bsdtar sets the
extended attributes before writing the file (because of the
information from [1]) and not after. And afaik security.capability is
the only one which get lost after file modification (for security
purpose). Anyway I contacted libarchive author about this problem so
it should be fixed in the next (major?) release.

[1] http://www.mail-archive.com/bug-tar@.../msg02053.html