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/
pgpr9p49SdBL3.pgp
Description: PGP signature
|