On Sat, Apr 06, 2002 at 06:28:42PM +0200, Andreas Gruenbacher wrote:
> > 1) some sort of mount options to change xattr semantecs, for example
>
> This does not address the real problem, and therefore makes no sense.
i agree, i was mainly looking for options to let me close this hole as
fast as possible.
> > 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.
yes.
> > 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.
because if you don't the DoS is not solved, there are several
directories on my system which must be mode 1777 (/tmp /var/tmp and so
on) they also must be owned by root, this allows me to use them to
bypass quota and completly fill the filesystem with xattrs. just take
my previous for loop and replace /dev/null with /tmp or /var/tmp or
any other convenient world writable root owned directory.
its NOT the same as cp /dev/zero /tmp since that can be controled with
quota, xattrs cannot.
> 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.
as would seperate permission bits for xattrs, but this is an extremely
intrusive change and means you have to start looking at abandoning
posix <whatever, i can't remember the acl number> and adopting
something closer to NTs. (personally i find NT acls a major PITA, for
90 of files standard unix mode bits are fine and must be avialable in
the tradidional manner...)
> 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.
i tend to agree, however we MUST address the issue of special files
which must be 1) world writable and 2) owned by root, this includes
1777 directories, they are just as vulnerable as /dev/null.
> 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.
i was merly referencing the permission bits they named `write extended
attribute' `append to extended attribute' and i think there is a
`create extended attribute' too but im not sure on that (i avoid
having to deal with NT like a root canal). note im actually
referencing 2000/XP which have a slightly different ACL model then NT4
but anyway...
> 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.
for regular files yes, directories are more complicated IMO. lets
examine it further:
a group of users are working on some project, and have various files
writable by a group which they are all members, only one may own the
file and he gets to bear the hit the file takes on his quota, he also
must accept that if one of the other group members decides to be a
prick he could cat /dev/zero into one of his group writable files and
exhaust his quota, the other user could equally well use xattrs too,
the affect is the same. so given this having different permissions
for xattr and file data doesn't get you anything (i really can't think
of situations with *regular* files where it really does, theoretically
depending on what sort of things you might start putting in xattrs you
might want to protect them more, but i doubt it). essentially we can
reasonably say `if you trust someone with read and/or write access to
the file content you also trust them to the same with xattrs'
now lets look at a user who has one or more either group or world
writable directories for people to `drop things off' this includes
people he may not trust as much as the above group scenerio, thus he
is careful not to leave any files writable by either world or
lesstrustedgroup, he need not worry about quota since anyone creating
files in his directory will retain ownership, and thus the quota
impact of the files they create, copying /dev/zero into his public
directory only b0rks thier own quota, not this user. here however
xattrs break this assumption, now the hostile user can apply hundreds
or thousands of xattrs filled with as much irrelevant data as they
will hold to exhaust the users quota.
the directory case also applies to sockets and fifos since these are
sometimes world writable (though perhaps this is just brokeness of
gnome/kde etc) so i think that keeping the regular file semantecs of
xattr permissions on these special files users are allowed to create
is also innappropriate. also note that sockets don't really have file
data so it doesn't hold the `if you trust the user to alter the data
you trust them to alter the xattrs' reasoning we established in
scenerio #1.
> 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.
indeed.
> 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.
indeed, this breaks the reasoning in scenerio #1 since device files
have no file content (not in the conventional sense anyway).
> 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.
i really can't think of any reason why you would need a user.*
attribute on a device, so i agree this is an acceptable solution.
system.* however should not be disallowed since its reasonable one may
wish to apply an ACL to a device file.
however it occurs to me that this could open another potential hole,
in the pty/tty case there is a hangup mechenism to ensure any process
holding a file descriptor is cut off when the tty is reset (you logout
and getty or whatever takes back the tty), getty also ensures to reset
permissions and ownership on the tty so past users cannot retain
access and thus sniff it for passwords or other useful data typed by a
future occupant. if however a user may apply an ACL which ensures
they are a supplimental user with read/write access to the tty and
login/getty whatever don't ensure to remove it a user could
sucessfully retain access to ttys after they relinquish it. i have
not yet attempted any tests on this.
> 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.
what systems actually make use of symlink permissions? i have yet to
encounter a unix where symlink perms were not entirely irrelevant,
even if you could change them (most you cannot). with XFS the
permissions are set to whatever your current umask dictates, however
setting umask to 0000 and creating a symlink which then has l---------
permissions still works fine for everyone (though looks quite odd).
> 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.
i suppose it all depends on what people end up wanting to do with EAs,
i tend to agree that there is unlikly to be very many if any useful
uses for such a thing, and it clearly won't work with the current
permission model.
> My conclusion, again, is to disallow user EA's for symlinks.
this would not bother me at all.
> 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.
i think the OWNER namespace could be useful, but i don't have specific
examples either.
> 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.
i agree.
> 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.
agreed.
> Did my arguing and conclusions make sense to you?
yes, in truth i was not at all sure of a correct solution so i
proposed a few somewhat half baked ones in the hope it would trigger
useful discussion, i see it worked perfectly ;-)
--
Ethan Benson
http://www.alaska.net/~erbenson/
pgpzhs3lIGES7.pgp
Description: PGP signature
|