[arch-general] file system capabilities
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
On Wed, Nov 4, 2009 at 10:12, Shridhar Daithankar <ghodechhap@ghodechhap.net> 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.
On Wed, Nov 4, 2009 at 10:14, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Wed, Nov 4, 2009 at 10:12, Shridhar Daithankar <ghodechhap@ghodechhap.net> 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.
Daenyth Blank wrote:
On Wed, Nov 4, 2009 at 10:14, Daenyth Blank <daenyth+arch@gmail.com> wrote:
On Wed, Nov 4, 2009 at 10:12, Shridhar Daithankar <ghodechhap@ghodechhap.net> 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_Setui... -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
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.
On Wed, Nov 4, 2009 at 3:15 PM, Jan de Groot <jan@jgc.homeip.net> 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) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe
On Wed, Nov 4, 2009 at 4:39 PM, Magnus Therning <magnus@therning.org> 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@gnu.org/msg02053.html
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...
participants (7)
-
Daenyth Blank
-
Gerardo Exequiel Pozzi
-
Jan de Groot
-
Magnus Therning
-
Shridhar Daithankar
-
Thomas Bächler
-
Xavier