Hi Mr. POSIX, ;-) > On Tue, 2009-08-25 at 20:38 +0200, Florian Zumbiehl wrote: > > > 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 > > > No, there really isn't. > > Let's go back to basics of the UNIX security. model, and most > importantly, how this is *interpreted* by applications. > > > The model is one of "grant". That is to say, that to be able to perform > any privileged action, you must be granted that privilege. > > Even your uid is a "grant" of privilege, it enables you to communicate > and change other processes running under that same uid. > > Likewise a gid is a "grant" of privilege. isn't that a bit at odds with the fact that the kernel does _not_ check against the accumulation of all of owner, group and others permissions that would apply to the process in question? Wouldn't really be all that difficult to implement, after all. > Therefore there is an assumption that a newly created user, with a > unique uid and gid not used anywhere, has effectively no privilege. > This assumption is used in many places, but most notably when daemons > and services run as a user of their own - or even the "nobody" user. > > Your example breaks this assertion. By giving a user or group *less* > privilege than other users, you have effectively granted a privilege to > "nobody" and secure users that genuine users *do not have*. Well, IMO you are mixing up what the userspace conventions of most desktop/server installations look like, and what the security model of the kernel is. Given that udev is nearly a component of the kernel, IMO it should follow the security model of the kernel, and not force userspace to follow any additional conventions. Think an embedded system that uses its own userspace implementation, but uses udev for managing its /dev. Or a chrooted session of some application-specific protocol that for some reason bind-mounts /dev. Not so much a user logging into a regular ssh remote shell. > Put simply, a mask should decrease in value when read from left to right > - 755 is valid, 577 isn't. Says who? > Giving a user or group less privilege than "anybody else" is easy to > circumvent, because the basic assumption is that by changing user or > adding a group you are *gaining* privilege. not dropping it - and thus > by switching to a "nobody" user you are *dropping* privilege not gaining > it. How is that a "basic assumption", given that the kernel implements the exact opposite, and that this exact opposite is documented behaviour? You didn't really answer a question the answer to which probably would be rather important in this context: Is there any way for a non-privileged process to drop a group membership without exec()ing? Also, I really would like to understand why the rename() in that scenario could fail, independent of whether we'll use that for anything. To point out another place where the kernel's model deviates from the "usual way things work in userspace": Capabilities. Yes, a lot of userspace programs do assume that uid 0 equals "is allowed to do anything". Still, the kernel does allow for uid 0 to be completely unprivileged. Should we now drop that from the kernel, given that it contradicts common assumptions about how userspace works, or is there maybe a point to supporting different userspace security models? 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
