Firstly, I've seen your other message, thanks for that. But I think I need to address some issues you raised.
On Sat, 30 Jun 2012, Guillem Jover <[email protected]> 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”. Yes. Also one thing to note is that there is caching of translations in the library. So if mcstransd stops between matchpathcon() and lsetfilecon() it doesn't just affect one lsetfilecon(), it affects every successive one for the same range - which for the MCS policy probably means every single file in the package. But I think the situation is a little more complex than that, if it was so simple then the race condition in question would be so rare that I probably wouldn't have found it. > I've to question some > things here though which would seem wrong with the SE Linux > infrastrucute or design (and not with dpkg itself). I think it's more of a problem in documentation. If the man pages fully explained what was happening then you would choose the raw variants because it's faster and simpler. Also the code that's currently in dpkg might even be older than the sensitivity range translation mechanism that's currently in use. > 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. If you wanted both then you would get the raw version and translate it into the non-raw version. If you want just the non-raw version then you ask for it and you get it. Like most libraries libselinux is designed around providing applications what they need. If there was a need for a different version then it would be provided. But generally people only need one of the two options. In this case dpkg happens to be using the option that is least well suited to it's operation. > 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? It certainly restarts the daemon during an upgrade, and if it didn't then that would be a bug which would need to be fixed. # dpkg -i policycoreutils_2.1.10-9_amd64.deb (Reading database ... 166749 files and directories currently installed.) Preparing to replace policycoreutils 2.1.10-9 (using policycoreutils_2.1.10-9_amd64.deb) ... [ ok ] Stopping restorecond (via systemctl): restorecond.service. [ ok ] Stopping mcstrans (via systemctl): mcstrans.service. Unpacking replacement policycoreutils ... Setting up policycoreutils (2.1.10-9) ... [ ok ] Starting mcstrans (via systemctl): mcstrans.service. [ ok ] Starting restorecond (via systemctl): restorecond.service. Processing triggers for man-db ... -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
