On Fri, 5 Apr 2002, Ethan Benson wrote:
>
> Hi,
>
> I have found an annoying problem with extended attributes in regards
> to security.
I just *knew* user EA's on symlinks and special files were fishy. It was
only recently that I have removed the code that was blocking user EA's for
those inodes, to conform with XFS semantics. How stupid of me!
> 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.
This does not address the real problem, and therefore makes no sense.
> 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.
This would be at least possible.
> 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.
Why should we introduce quircks like this? All the messing around with the
sticky bit for directories has a single reason: The rwx permission scheme
just is too weak to allow everybody to create files, without also allowing
everybody to delete arbitrary files.
For many it may be hard to admit that the directory sticky bit thing is an
ugly workaround for emulating create permissions. Even POSIX ACLs don't
solve this, but additional permissions such as create and delete would
provide a clean solution.
> 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).
Apart from being more complicated to implement, permissions for individual
EA's would also be much more difficult to understand, and to use
correctly, and we would need a tool for manipulating them. I am very much
opposed to this idea, as this seems overly complex, and completely
unnecessary.
The comparison with Windows NT is not valid for several reasons: (a)
Windows NT does not have device special files, so we have to deal with
different semantics. (b) Windows NT does not use EA's, but uses forks,
similar to the Macintosh HFS. Forks are the same as regular files, they
are only "hidden" behind the name of another file.
The first question we should try to answer is, what are the semantics of
user EA's for special files and inodes, and do they make sense. We have
defined user EA's as attributes users may associate with a file, according
to the same access restrictions as the file contents. I think these
semantics are clear, and easy to understand.
Now for symlinks and special files the permissions have a different
meaning. Let's first discuss special files.
The permissions of a special file inode denote which accesses are
permitted to the device the inode is describing. It is possible to have a
device inode, such as /dev/null, on a read-only file system, and it's
still permitted to make information disappear by piping it to /dev/null.
If we use the same permissions to determine the permissions for special
file EA's, then we end up with the anomaly (and security hole) that Ethan
has described.
If we use different rules such as inode ownership to determine access,
then the semantics become relatively complicated. I think this is neither
necessary nor useful.
So my conclusion is that we should disallow user EA's for special files.
For symlinks the situation is similar. The permissions of a symlink have
nothing to do with the contents of the symlink, but they denote permission
to traverse the symlink. Also, the traditional Linux file systems ext2 and
ext3 don't even allow permissions for symlinks; the permissions are always
initialized with S_IRWXUGO.
Again, one of the questions that come to mind is, do we have a need for
symlink user EA's? With the existing user EA permission model, I don't see
any reason supporting this.
My conclusion, again, is to disallow user EA's for symlinks.
We have been discussing useful EA namespaces before. In addition to the
system and user namespaces, we had two additional namespaces that might be
useful future extensions. I have recently given this description of these
EA namespace on the ext2-devel mailing list:
SYSTEM
Used internally by the kernel; access permissions depend on the policy
implemented in the kernel, and may differ from attribute to attribute.
There may be restrictions on the values that a system attribute may
obtain, e.g., ACL values must be valid.
USER
Attributes regular users can use. Read and write access is controlled
by the usual file permissions, so everyone who is allowed X access to
the file data is also allowed X acces on its user EA's.
TRUSTED
Attributes only trusted processes may use. This would be useful for
implementing OS extensions in user space that use EA's which must not
otherwise be accessible to users. Another application could be backup
labels, for example. The trust status of a process could be defined by
a capability.
OWNER
Attributes only accessible to the owner of an object. This is a bit
obscure; I have no good example for this namespace.
The set of namespaces proposed above ties the permissions needed for
accessing a class of EA's to the namespace. I think this is a very useful
simplification. The system namespace is a bit of an exception, since the
permissions differ between individual system attributes. This is necessary
to support the semantics of ACLs, Capabilities, MAC and audit labels, etc.
through the EA interfaces; I think this special role of the system
namespace is an acceptable compromise, instead of introducing separate
namespaces for each slightly differing new concept we may add in the
future.
Ethan's option (2) amounts to the semantics of the proposed owner
namespace. I suggest not to mix semantics within the user namespace. It
may some day turn out that the owner namespace is a useful thing, for
files, directories, special files, etc. That would be the day to introduce
the owner namespace. Keeping the user and owner namespaces distinct is
much more transparent semantically.
> ignoring it is not an acceptable option IMO since i consider it a
> security hole that users may attach attributes to system files.
Quite right.
Did my arguing and conclusions make sense to you?
Cheers,
Andreas.
|