Tags Tags

Bug#679641: dpkg: if mcstransd is unexpectedly stopped then dpkg uses invalid SE Linux context

June 30th, 2012 - 08:10 am ET by Russell Coker | Report spam
Help Create a new topic
Package: dpkg
Version: 1.16.4.3
Severity: normal

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.

This can happen when dpkg upgrades multiple packages including policycoreutils
(which contains mcstransd). A mitigating factor for the users is that it's
recommended that upgrades of SE Linux policy and related packages (including
policycoreutils) between Debian releases be done in permissive mode with a
full relabel afterwards. But if someone upgraded from Squeeze to Testing a
few weeks ago and then upgraded to the latest Testing today it would mess
things up.

Error setting security context for next file object:: Invalid argument

To demonstrate this problem instruct dpkg to install a couple of big packages
(I use libreoffice-common and libreoffice-core) and then stop mcstransd while
dpkg is working. You may need to do it two or three times to get it to happen.
If the system is in permissive mode then the string "SystemLow" will be
included in contexts written to disk and in enforcing mode dpkg will write a
message such as the above to stderr. In both cases a message such as the
below will be written to the audit log (or the kernel message log if auditd
isn't running).

type=AVC msg=audit(1341055747.187:1390): avc: denied { mac_admin } for pid131 comm="dpkg" capability3 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=capability2


Debian Release: wheezy/sid
APT prefers testing
APT policy: (350, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages dpkg depends on:
ii libbz2-1.0 1.0.6-3
ii libc6 2.13-33
ii liblzma5 5.1.1alpha+20120614-1
ii libselinux1 2.1.9-5
ii tar 1.26-4
ii zlib1g 1:1.2.7.dfsg-13

dpkg recommends no packages.

Versions of packages dpkg suggests:
ii apt 0.9.7




To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
email Follow the discussionReplies 3 repliesReplies Make a reply

Replies

#1 Guillem Jover
June 30th, 2012 - 09:10 am ET | Report spam
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
with a subject of "unsubscribe". Trouble? Contact

Similar topics

Make your own search :