Hi! On Sat, 2012-06-30 at 21:59:13 +1000, Russell Coker wrote: > I am giving this bug "normal" severity, but for certain types of SE Linux use > it might be regarded as more severe. > > 1) rjc:user_r:user_t:s0-s0:c0.c1023 > 2) rjc:user_r:user_t:SystemLow-SystemHigh > > The way things currently work is that dpkg converts the sensitivity range of > a file from the computer readable form to the human readable form (the first > of > the above two lines to the second). Then before writing the data to disk it > converts it back to the first form. mcstransd is used for the conversions > both ways, if it's running when dpkg tries to convert from #1 to #2 but not > running when dpkg wants to convert from #2 to #1 then dpkg will try to write > #2 to disk, which is a violation of SE Linux policy.
Well, dpkg is only calling matchpathcon() and lsetfilecon() one after the other, so this is happening “transparently”. I've to question some things here though which would seem wrong with the SE Linux infrastrucute or design (and not with dpkg itself). If there's this transparent conversion happening, why do those functions thow away the computer readable form when converting to the human readable form? I'm guessing the problem is due to security_context_t being a string, so more elaborate information cannot be kept there. If the former was not thrown away then there would be no problem for the code internally to fallback to use that if the daemon is not running any longer. I've just quickly checked policycoreutils and it does not seem to be sopping or restarting the daemon during upgrades, so I'm guessing this can only happen if the daemon dies for whatever reason or the user stops it explicitly. The latter would be user error, the former seems to imply that the design of the infrastructure is a bit flaky? Given the above, I'm very inclined to think there's nothing wring with dpkg in itself and that this is a shortcoming in some (or multiple) of the SE Linux support packages. Poiting out alternative API usage that might allow to make the code robust against this situation and be used to explicitly fallback to something else would be good if that exists, otherwise I think I'll just reassign to policycoreutils. thanks, guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
