Hi, I have found an annoying problem with extended attributes in regards to security. normal user.* attributes are controlled by the file's standard permission bits (or acl), however this becomes a bit of a problem on device files in /dev many of which must be world writable. my security policy involves farming off /usr, /var, /tmp, and /home to other filesystems to ensure unprivileged users have NO write access to / whatsoever, world writable devices don't count since writing to them does not actually write to the root filesystem. given this policy there is no need for quotas on / however users are allowed to apply an unlimited number of extended attributes to /dev/pty*, /dev/null and other assorted devices which must be writable. not only does this potentially allow users to fill up the / partition with hundreds of attributes containing irrelevant data, it allows them to squirrel away data in a semi hidden way. i have also found that this has the interesting side affect of making symlink permissions not so irrelevant, users may apply extended attributes to world writable symlinks (using the -h switch to setfattr) but not to non-writable symlinks. again this is annoying given filesystems converted from ext2 or similar via cpio will have all symlinks world writable instead of 755 (or whatever the umask dictates on creation of the link). the way i see it there are only a few options for fixing these issues: 1) some sort of mount options to change xattr semantecs, for example perhaps nouattr to disallow unprivileged users to apply user.* attributes (or maybe restrict to file owner regardless of the permission bits), this would be mostly sufficient to fix my gripe, i would just mount / with nouattr, it may not solve other world writable directories on the system, or symlinks. 2) apply a different sementec on special files, for regular files and directories use the current method of using the permission bits to control access to xattrs, but for special files such as block devices, char devices, sockets etc only allow the file's owner to add/remove xattrs. 3) for directories, only allow xattrs to be written by the directories owner if the sticky bit is set (this would prevent users from spewing attrs on /tmp /var/tmp and other world writable sticky system directories. 4) add a seperate ACL for control of xattrs, this is the approach NT takes (actually to be more specific NT ACLs have seperate read and write permission bits for the xattr and the file data itself). IMO option 4 is probably the cleanest most consistent solution, but also the least trivial to implement. a combination of option 2 and 3 seems to be to be fairly natural and would solve the most common places where using permission bits to control xattrs is clearly innappropriate (/dev/* 1777 system dirs symlinks etc). ignoring it is not an acceptable option IMO since i consider it a security hole that users may attach attributes to system files. the symlink issue is especially annoying since there isn't a real way to change symlink permissions other then changing your umask and recreating the symlink (it also violates the anchient understanding that symlink permissions are irrelevant). -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgp00001.pgp
Description: PGP signature