On Wed, 2007-07-18 at 14:03 -0400, Stephen Smalley wrote: > On Wed, 2007-07-18 at 12:53 -0500, Serge E. Hallyn wrote: > > Quoting Andrew Morgan ([EMAIL PROTECTED]): > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > Serge, > > > > > > I spent the evening getting my local build of libcap (building the > > > libcap/progs/old/setcap and getcap tools) working with the new kernel > > > support. > > > > > > It seems there is a basic insecurity bug in the xattr support insofar as > > > doing the following does not delete the capabilities on a file when I > > > copy over it...: > > > > > > [EMAIL PROTECTED] progs]$ cd ~ > > > [EMAIL PROTECTED] progs]$ cp /bin/ping . > > > [EMAIL PROTECTED] progs]$ ./ping localhost > > > [EMAIL PROTECTED] progs]$ ping: icmp open socket: Operation not permitted > > > [EMAIL PROTECTED] progs]$ sudo setcap cap_net_raw=ep ping > > > [EMAIL PROTECTED] progs]$ getcap ping > > > Capabilities for `ping': > > > = cap_net_raw+ep > > > [EMAIL PROTECTED] progs]$ ./ping localhost > > > 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=64 > > > time=0.056 ms64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 > > > ttl=64 time=0.058 ms > > > <Ctrl-C> > > > - --- localhost.localdomain ping statistics --- > > > 2 packets transmitted, 2 received, 0% packet loss, time 1009ms > > > rtt min/avg/max/mdev = 0.056/0.057/0.058/0.001 ms, pipe 2 > > > [EMAIL PROTECTED] progs]$ cp /bin/ping . > > > [EMAIL PROTECTED] progs]$ ./ping localhost > > > PING localhost.localdomain (127.0.0.1) 56(84) bytes of data. > > > 64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=0 ttl=64 > > > time=0.057 ms64 bytes from localhost.localdomain (127.0.0.1): icmp_seq=1 > > > ttl=64 time=0.056 ms > > > - --- localhost.localdomain ping statistics --- > > > 2 packets transmitted, 2 received, 0% packet loss, time 1008ms > > > rtt min/avg/max/mdev = 0.056/0.056/0.057/0.007 ms, pipe 2 > > > > > > This last operation should have failed (Operation not permitted). > > > > Boy, that is messed up. The xattrs are attached to the inode, so no way > > should that happen. > > Overwriting the existing file won't change the inode. > For suid, this is handled by remove_suid -> notify_change with > ATTR_KILL_SUID/SGID. No equivalent for security xattrs presently.
Oh, and you don't want to just remove security.selinux in that case, so if you do that for security.cap, don't make it apply to all security. attributes. -- Stephen Smalley National Security Agency - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
