On Thu, 2010-07-29 at 15:20:29 +1000, Russell Coker wrote: > On Thu, 29 Jul 2010, Guillem Jover <guil...@debian.org> wrote: > > > For files in /usr/sbin it seems that both code paths that call > > > set_selinux_path_context() are being executed, it would be good if we > > > could only call set_selinux_path_context() once as it's not the fastest > > > function... > > > > The two calls should be operating on different paths, the first one > > does on the new extracted object, the second one operates on the > > backup symlink used in case of roll back (which has to be manually > > copied, because it cannot be hardlinked). > > What do you mean by this?
Sorry, I guess this assumed some deep understanding of how dpkg operates internally. I'll try to give an overview (obviating some corner-cases and other uninteresting details). > If you are keeping a second copy of the file around then it should have the > same label. SE Linux labels can (depending on policy) cause a domain > transition that reduce the privileges after the exec() call. If we have a > SUID binary could the current code result in a SUID copy of it that has a > label based on the backup name instead of the real name? If so then it's a > security problem as a program may run with a superset of the privileges of > the > calling code. > > Even if the program is not SUID it's still a potential security problem for > the case where a non-SUID program should run with less privileges than the > calling code. On unpack, dpkg extracts the new object as <pathname.dpkg-new>, as this is a newly created object it needs all permissions and labels set anew, the SE Linux label for <pathname.dpkg-new> is set as if it was <pathname> (that's why the set_selinux_path_context function has a matchpath arg representing <pathname>, and a path arg representing <pathname.dpkg-new> or <pathname.dpkg-tmp>). Then to be able to roll-back in case of failure, dpkg makes a backup of the existing object, for most file types that's just a hardlink, for dirs if it needs to replaces them, then it just renames them (to take them out of the way as we cannot atomicaly replace them later on), and for symlinks as they cannot be hardlinked it needs to create a new <pathname.dpkg-tmp> symlink with the same contents as the <pathname> one. But as this one is a newly created object it needs the permissions and SE Linux labels applied to it, otherwise if we need to roll-back with rename(2) from <pathname.dpkg-tmp> to <pathname> it would not have the correct metadata. Hope this explains a bit more clearly. > > > To reproduce this bug run a system with SE Linux enabled, install the > > > package policycoreutils, and then run the command "restorecon -R -v > > > /usr/sbin", if things work correctly then all objects contained in the > > > package will have the correct context and restorecon will not display > > > any output. But the way things work currently is that "restorecon -R > > > -v /usr/sbin" gives the following output: > > > restorecon reset /usr/sbin/load_policy context > > > system_u:object_r:load_policy_exec_t:s0->system_u:object_r:bin_t:s0 > > > > I don't feel like setting up a SE Linux environment, the fix should be > > available for 1.15.8, so if it does not fix your problem, please > > reopen this bug report! > > Sure. > > Incidentally if I gave you root access to a SE Linux system would you be > interested in trying it out? Hmm, not right now, too much stuff on my TODO list already, thanks for the offer though, maybe another time! regards, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
