Hi, > Sure, let's invert the chmod() and chown()... > > BUT WAIT! > > Assumption: > > /dev/foo is configured to be owned by user mrposix, mode 0466. The > attacker (mrposix) tries to open /dev/foo for writing. > > The Trace: > > action | owner | mode | open(O_WRONLY)? > ------------------------------+---------+---------+----------------- > mknod(/dev/foo) | root | 0644 | no > chown(/dev/foo,mrposix,users) | mrposix | 0644 | yes > chmod(/dev/foo,0466) | mrposix | 0466 | no > > > In other words, exactly the same race. > > Since we don't have a chownmod syscall, we have to do this > non-atomically, which means that either there's a race for denying > access for particular users or a race for denying access for particular > groups. > > > Now, let's put aside for a moment the fact that either of these modes is > insane. Which of the two attempts to deny access _should_ work? > > The surprising answer is that the attempt to deny access to the *user* > is the one that should work (ie. don't change the code), not the attempt > to deny access to a group. In the further text, you assume that the user can execute arbitrary code - in that case, though, the owner can change the permissions of his own files, so you can't really deny much. But yeah, just reordering the calls obviously doesn't avoid the problem. > There's a simple reason for this. > > A user's uid is fixed, and is a key fact of that user's privilege. The > only way for "mrposix" to change users is if he was really root in the > first place, or has access to a setuid program. > > A user's gid *is not* fixed, in fact, a user may be a member of any one > or more groups at their own choice. An entry in /etc/passwd > or /etc/groups does not *force* the user into those groups, it simply > grants the user *access* to be a member of those groups. > > There are tried, tested and (most importantly) *permitted* methods for a > user to shed group membership. Since a user can shed their group > membership in this way, they can work around your attempt to restrict > access, and thus grant themselves write access after all. There are? In the kernel? > (This is, in fact, why it's "insane" to deny access using modes; a user > can always find a way to become *less* privileged, and thus if you're > trying to deny them access to things, actually gain privilege) As kindof noted above, I think that cases of users capable of doing read- and write-accesses but not of executing arbitrary code should be considered. Or in more general terms: Well, yeah, there probably are many userspace configurations where such permissions would not be a wise thing to use. But still, there probably are just as many cases that are perfectly safe - and I think that udev should not decide for the user which kinds of "odd" permissions with otherwise well-defined effects they are supposed to use, in particular so if it's not documented (which I suppose it's not?) Florian -- To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
