For some reason restorecon and setfiles have different notions of what context certain files should be. For example:
# ls -Z /usr/lib/libz.* -rwxr-xr-x+ root root system_u:object_r:lib_t /usr/lib/libz.a lrwxrwxrwx+ root root system_u:object_r:lib_t /usr/lib/libz.so -> libz.so.1.2.1.1 lrwxrwxrwx root root system_u:object_r:lib_t /usr/lib/libz.so.1 -> libz.so.1.2.1.1 -rwxr-xr-x root root system_u:object_r:shlib_t /usr/lib/libz.so.1.2.1.1
# restorecon -v /usr/lib/libz.* restorecon set context /usr/lib/libz.so->system_u:object_r:shlib_t restorecon set context /usr/lib/libz.so.1->system_u:object_r:shlib_t
# setfiles -v /etc/security/selinux/file_contexts /usr/lib/libz.* setfiles: read 1450 specifications setfiles: labeling files under /usr/lib/libz.a setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1 setfiles: labeling files under /usr/lib/libz.so setfiles: relabeling /usr/lib/libz.so from system_u:object_r:shlib_t to system_u:object_r:lib_t setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1 setfiles: labeling files under /usr/lib/libz.so.1 setfiles: relabeling /usr/lib/libz.so.1 from system_u:object_r:shlib_t to system_u:object_r:lib_t setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1 setfiles: labeling files under /usr/lib/libz.so.1.2.1.1 setfiles: hash table stats: 1 elements, 1/65536 buckets used, longest chain length 1 setfiles: Done.
So, restorecon thinks that *.so files should be shlib_t, whereas setfiles thinks they should be lib_t. Which one is right and why do they disagree? I thought that they both get their context info from the same place.
This is with policy-1.11.3-5 and policycoreutils-1.11-4.
gary
On 18.05.2004 19:22, Gary Peck wrote:
For some reason restorecon and setfiles have different notions of what context certain files should be. For example:
[...]
So, restorecon thinks that *.so files should be shlib_t, whereas setfiles thinks they should be lib_t. Which one is right and why do they disagree? I thought that they both get their context info from the same place.
It seems the two disagree on symlinks. May be restorecon forgets to check whether its argument is a symlink?
Aleksey Nogin wrote:
On 18.05.2004 19:22, Gary Peck wrote:
For some reason restorecon and setfiles have different notions of what context certain files should be. For example:
[...]
So, restorecon thinks that *.so files should be shlib_t, whereas setfiles thinks they should be lib_t. Which one is right and why do they disagree? I thought that they both get their context info from the same place.
It seems the two disagree on symlinks. May be restorecon forgets to check whether its argument is a symlink?
Looks like a bug in matchpathcon (Which is used buy restorecon). It is returning the wrong security context. I will send this to stephen. Basically looks like it is ignoring file type.
Dan
On Tue, 2004-05-18 at 23:07, Daniel J Walsh wrote:
Looks like a bug in matchpathcon (Which is used buy restorecon). It is returning the wrong security context. I will send this to stephen. Basically looks like it is ignoring file type.
matchpathcon takes a pathname and optional file mode as input parameters for matching against the file contexts configuration. It doesn't attempt to stat the file itself to obtain the mode because it is sometimes used by programs that are creating new files (e.g. udev) and want to know the context for the file they are about to create, so it requires the caller to provide the mode. restorecon currently passes 0 as the mode, so no mode matching is performed.
So this is a bug in restorecon; it needs to be changed to stat the file and provide the mode.
Stephen Smalley wrote:
On Tue, 2004-05-18 at 23:07, Daniel J Walsh wrote:
Looks like a bug in matchpathcon (Which is used buy restorecon). It is returning the wrong security context. I will send this to stephen. Basically looks like it is ignoring file type.
matchpathcon takes a pathname and optional file mode as input parameters for matching against the file contexts configuration. It doesn't attempt to stat the file itself to obtain the mode because it is sometimes used by programs that are creating new files (e.g. udev) and want to know the context for the file they are about to create, so it requires the caller to provide the mode. restorecon currently passes 0 as the mode, so no mode matching is performed.
So this is a bug in restorecon; it needs to be changed to stat the file and provide the mode.
policycoreutils-1.12-2 has two fixes for restorecon, it handles the symbolic link problem and ignores <<none>>.
Dan
matchpathcon takes a pathname and optional file mode as input parameters for matching against the file contexts configuration. It doesn't attempt to stat the file itself to obtain the mode because it is sometimes used by programs that are creating new files (e.g. udev) and want to know the context for the file they are about to create, so it requires the caller to provide the mode. restorecon currently passes 0 as the mode, so no mode matching is performed.
So this is a bug in restorecon; it needs to be changed to stat the file and provide the mode.
Looks like a similar bug might be present in rpm, or at least the end result is similar. Whenever I install new RPM's from Rawhide, *.so* files get installed with object_r:lib_t context. If I run "/sbin/fixfiles restore" right afterward, they get relabeled back to object_r:shlib_t. Either rpm has an old policy version on the Rawhide build machines, or it's not labeling files correctly.
Also, the dev package in Rawhide comes with all files labeled as object_r:device_t. After running fixfiles, some of those get relabeled to the correct object_r:fixed_disk_device_t, object_r:tty_device_t, object_r:sound_device_t, etc. dev should have the correct contexts to begin with. Various files in /usr/sbin also don't have the correct contexts as shipped in the RPM's.
This is all with selinux-policy-targeted-1.13.8-1, policycoreutils-1.13.3-2, and rpm-4.3.2-0.4.
Gary
On Fri, 2004-06-25 at 12:34, Gary Peck wrote:
Looks like a similar bug might be present in rpm, or at least the end result is similar. Whenever I install new RPM's from Rawhide, *.so* files get installed with object_r:lib_t context. If I run "/sbin/fixfiles restore" right afterward, they get relabeled back to object_r:shlib_t. Either rpm has an old policy version on the Rawhide build machines, or it's not labeling files correctly.
Also, the dev package in Rawhide comes with all files labeled as object_r:device_t. After running fixfiles, some of those get relabeled to the correct object_r:fixed_disk_device_t, object_r:tty_device_t, object_r:sound_device_t, etc. dev should have the correct contexts to begin with. Various files in /usr/sbin also don't have the correct contexts as shipped in the RPM's.
This is all with selinux-policy-targeted-1.13.8-1, policycoreutils-1.13.3-2, and rpm-4.3.2-0.4.
I don't believe that rpm is computing file contexts at package build time anymore, since there are multiple policies (strict and targeted) now. It should instead compute the file contexts when unpacking the package based on your local file_contexts configuration, whose path is obtained from /usr/lib/rpm/macros using /etc/selinux/config to determine the active policy. It seems to be working for me.
Stephen Smalley wrote:
On Fri, 2004-06-25 at 12:34, Gary Peck wrote:
Looks like a similar bug might be present in rpm, or at least the end result is similar. Whenever I install new RPM's from Rawhide, *.so* files get installed with object_r:lib_t context. If I run "/sbin/fixfiles restore" right afterward, they get relabeled back to object_r:shlib_t. Either rpm has an old policy version on the Rawhide build machines, or it's not labeling files correctly.
Also, the dev package in Rawhide comes with all files labeled as object_r:device_t. After running fixfiles, some of those get relabeled to the correct object_r:fixed_disk_device_t, object_r:tty_device_t, object_r:sound_device_t, etc. dev should have the correct contexts to begin with. Various files in /usr/sbin also don't have the correct contexts as shipped in the RPM's.
This is all with selinux-policy-targeted-1.13.8-1, policycoreutils-1.13.3-2, and rpm-4.3.2-0.4.
I don't believe that rpm is computing file contexts at package build time anymore, since there are multiple policies (strict and targeted) now. It should instead compute the file contexts when unpacking the package based on your local file_contexts configuration, whose path is obtained from /usr/lib/rpm/macros using /etc/selinux/config to determine the active policy. It seems to be working for me.
Any chance the so files are getting created in a post install script? rpm should be working the same as restorecon and setfiles.
Dan
On Fri, 2004-06-25 at 12:56, Daniel J Walsh wrote:
Any chance the so files are getting created in a post install script? rpm should be working the same as restorecon and setfiles.
The .so symlink might be created by %post, but that is ok, as it just gets the type of the parent directory anyway. Only the actual shared object should have shlib_t, and that should be installed by rpm.
rpm source code appears to be passing the mode as part of the lookup, so I don't think that is the issue.
rpm -Uvh --force libselinux*.rpm keeps the correct security context on /lib/libselinux.so.1 for me, both on a strict policy machine and a targeted policy machine. rpm is 4.3.2-0.4; I haven't updated to -1 yet.
On Fri, Jun 25, 2004 at 01:44:15PM -0400, Stephen Smalley wrote:
rpm source code appears to be passing the mode as part of the lookup, so I don't think that is the issue.
rpm -Uvh --force libselinux*.rpm keeps the correct security context on /lib/libselinux.so.1 for me, both on a strict policy machine and a targeted policy machine. rpm is 4.3.2-0.4; I haven't updated to -1 yet.
Could this be an issue with apt? I'm actually using apt-get to install these packages. When I tried using "rpm -Uvh ..." directly, it seemed to set the contexts correctly as you say. However, when I did it with apt-get again, I saw the same problem. Here's some files from the mozilla package with their correct contexts:
system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaccessibility.so system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaddrbook.so system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libappcomps.so system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libautoconfig.so
Then I run "apt-get install mozilla", which upgrades mozilla from 1.7-0.3.1 to 1.7-0.3.2. Afterwards, these same files (but from the new version of mozilla) have the following contexts:
root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaccessibility.so root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaddrbook.so root:object_r:lib_t /usr/lib/mozilla-1.7/components/libappcomps.so root:object_r:lib_t /usr/lib/mozilla-1.7/components/libautoconfig.so
I assumed that apt's behaviour should be the same since it's just using rpm underneath, but maybe there's extra rpm API calls that need to be made by apt when it's running on a SELinux system?
This is with apt-0.5.15cnc6-0.fdr.11.2, rpm-4.3.2-0.4.
gary
On Sat, Jun 26, 2004 at 05:12:34PM -0700, Gary Peck wrote:
Could this be an issue with apt? I'm actually using apt-get to install these packages. When I tried using "rpm -Uvh ..." directly, it seemed to set the contexts correctly as you say. However, when I did it with apt-get again, I saw the same problem. Here's some files from the mozilla package with their correct contexts:
system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaccessibility.so system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaddrbook.so system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libappcomps.so system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libautoconfig.so
Then I run "apt-get install mozilla", which upgrades mozilla from 1.7-0.3.1 to 1.7-0.3.2. Afterwards, these same files (but from the new version of mozilla) have the following contexts:
root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaccessibility.so root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaddrbook.so root:object_r:lib_t /usr/lib/mozilla-1.7/components/libappcomps.so root:object_r:lib_t /usr/lib/mozilla-1.7/components/libautoconfig.so
I assumed that apt's behaviour should be the same since it's just using rpm underneath, but maybe there's extra rpm API calls that need to be made by apt when it's running on a SELinux system?
This is with apt-0.5.15cnc6-0.fdr.11.2, rpm-4.3.2-0.4.
Ok, I'm pretty sure it's an apt problem now. I tried installing the same package twice, once with apt using the rpm API directly (apt-get install ...), and once with apt calling the rpm binary externally (apt-get -o RPM::PM="external" install ...). When using the API, I see the same problem as above. When calling the rpm binary, the contexts get set correctly.
I've CC'ed the apt-rpm list as it's probably a more appropriate place for this discussion. Anyone there care to comment?
gary
On Sat, 26 Jun 2004, Gary Peck wrote:
On Sat, Jun 26, 2004 at 05:12:34PM -0700, Gary Peck wrote:
Could this be an issue with apt? I'm actually using apt-get to install these packages. When I tried using "rpm -Uvh ..." directly, it seemed to set the contexts correctly as you say. However, when I did it with apt-get again, I saw the same problem. Here's some files from the mozilla package with their correct contexts:
system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaccessibility.so system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libaddrbook.so system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libappcomps.so system_u:object_r:shlib_t /usr/lib/mozilla-1.7/components/libautoconfig.so
Then I run "apt-get install mozilla", which upgrades mozilla from 1.7-0.3.1 to 1.7-0.3.2. Afterwards, these same files (but from the new version of mozilla) have the following contexts:
root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaccessibility.so root:object_r:lib_t /usr/lib/mozilla-1.7/components/libaddrbook.so root:object_r:lib_t /usr/lib/mozilla-1.7/components/libappcomps.so root:object_r:lib_t /usr/lib/mozilla-1.7/components/libautoconfig.so
I assumed that apt's behaviour should be the same since it's just using rpm underneath, but maybe there's extra rpm API calls that need to be made by apt when it's running on a SELinux system?
This is with apt-0.5.15cnc6-0.fdr.11.2, rpm-4.3.2-0.4.
Ok, I'm pretty sure it's an apt problem now. I tried installing the same package twice, once with apt using the rpm API directly (apt-get install ...), and once with apt calling the rpm binary externally (apt-get -o RPM::PM="external" install ...). When using the API, I see the same problem as above. When calling the rpm binary, the contexts get set correctly.
I've CC'ed the apt-rpm list as it's probably a more appropriate place for this discussion. Anyone there care to comment?
I wouldn't call it an apt-problem, you just need to put it into same context as rpm. This should already be the case on Fedora Core 2, dunno about upstream selinux policy packages - this is from stock FC2 /etc/security/selinux/src/policy/file_contexts/program/rpm.fc: /usr/bin/apt-get -- system_u:object_r:rpm_exec_t /usr/bin/apt-shell -- system_u:object_r:rpm_exec_t /usr/bin/synaptic -- system_u:object_r:rpm_exec_t
- Panu -
On Mon, 2004-06-28 at 09:11, Panu Matilainen wrote:
I wouldn't call it an apt-problem, you just need to put it into same context as rpm. This should already be the case on Fedora Core 2, dunno about upstream selinux policy packages - this is from stock FC2 /etc/security/selinux/src/policy/file_contexts/program/rpm.fc: /usr/bin/apt-get -- system_u:object_r:rpm_exec_t /usr/bin/apt-shell -- system_u:object_r:rpm_exec_t /usr/bin/synaptic -- system_u:object_r:rpm_exec_t
It isn't just a policy issue; rpm had to be modified for SELinux to set file security contexts when creating files. Those changes are in the upstream rpm, and yum seems to work as expected when updating.
On Mon, Jun 28, 2004 at 02:53:52PM -0400, Stephen Smalley wrote:
On Mon, 2004-06-28 at 09:11, Panu Matilainen wrote:
I wouldn't call it an apt-problem, you just need to put it into same context as rpm. This should already be the case on Fedora Core 2, dunno about upstream selinux policy packages - this is from stock FC2 /etc/security/selinux/src/policy/file_contexts/program/rpm.fc: /usr/bin/apt-get -- system_u:object_r:rpm_exec_t /usr/bin/apt-shell -- system_u:object_r:rpm_exec_t /usr/bin/synaptic -- system_u:object_r:rpm_exec_t
The context is not the problem. I'm running the targeted policy from FCdev, which makes both /bin/rpm and /usr/bin/apt* system_u:object_r:bin_t. rpm works fine, however, whereas apt-get does not.
It isn't just a policy issue; rpm had to be modified for SELinux to set file security contexts when creating files. Those changes are in the upstream rpm, and yum seems to work as expected when updating.
I believe apt needs similar modifications. The attached patch to apt fixes the problem for me. I'm not too familiar with rpm, apt, or selinux internals, so this patch might need some work. I just took the code from rpm's lib/rpminstall.c/rpmInstall() function which seemed to be missing in apt's apt-pkg/rpm/rpmpm.cc/pkgRPMLibPM::Process() function.
Before the patch, running "apt-get install --reinstall zlib" produced this result: # rpm -q --fscontext zlib /usr/lib/libz.so.1 root:object_r:lib_t /usr/lib/libz.so.1.2.1.1 root:object_r:lib_t /usr/share/doc/zlib-1.2.1.1 system_u:object_r:usr_t /usr/share/doc/zlib-1.2.1.1/README system_u:object_r:usr_t
After the patch, running "apt-get install --reinstall zlib" produced this result: # rpm -q --fscontext zlib /usr/lib/libz.so.1 system_u:object_r:lib_t /usr/lib/libz.so.1.2.1.1 system_u:object_r:shlib_t /usr/share/doc/zlib-1.2.1.1 system_u:object_r:usr_t /usr/share/doc/zlib-1.2.1.1/README system_u:object_r:usr_t
The correct result, according to rpm, is the second one: # rpm -q --recontext zlib /usr/lib/libz.so.1 system_u:object_r:lib_t /usr/lib/libz.so.1.2.1.1 system_u:object_r:shlib_t /usr/share/doc/zlib-1.2.1.1 system_u:object_r:usr_t /usr/share/doc/zlib-1.2.1.1/README system_u:object_r:usr_t
gary
On Mon, 28 Jun 2004, Gary Peck wrote:
On Mon, Jun 28, 2004 at 02:53:52PM -0400, Stephen Smalley wrote:
On Mon, 2004-06-28 at 09:11, Panu Matilainen wrote:
I wouldn't call it an apt-problem, you just need to put it into same context as rpm. This should already be the case on Fedora Core 2, dunno about upstream selinux policy packages - this is from stock FC2 /etc/security/selinux/src/policy/file_contexts/program/rpm.fc: /usr/bin/apt-get -- system_u:object_r:rpm_exec_t /usr/bin/apt-shell -- system_u:object_r:rpm_exec_t /usr/bin/synaptic -- system_u:object_r:rpm_exec_t
The context is not the problem. I'm running the targeted policy from FCdev, which makes both /bin/rpm and /usr/bin/apt* system_u:object_r:bin_t. rpm works fine, however, whereas apt-get does not.
Ok, the policy has changed in the development tree since FC2 release, apt-rpm *was* working ok with the above context settings the last I looked.
It isn't just a policy issue; rpm had to be modified for SELinux to set file security contexts when creating files. Those changes are in the upstream rpm, and yum seems to work as expected when updating.
I believe apt needs similar modifications. The attached patch to apt fixes the problem for me. I'm not too familiar with rpm, apt, or selinux internals, so this patch might need some work. I just took the code from rpm's lib/rpminstall.c/rpmInstall() function which seemed to be missing in apt's apt-pkg/rpm/rpmpm.cc/pkgRPMLibPM::Process() function.
Much of the code in pkgRPMLibPM is lifted more-or-less directly from rpmInstall(), no problem with that :) I'll have a closer look at this one of these days but basically the patch seems fine to me if that's what rpm itself does.
- Panu -
On Tue, 2004-06-29 at 01:32, Gary Peck wrote:
On Mon, Jun 28, 2004 at 02:53:52PM -0400, Stephen Smalley wrote:
On Mon, 2004-06-28 at 09:11, Panu Matilainen wrote:
I wouldn't call it an apt-problem, you just need to put it into same context as rpm. This should already be the case on Fedora Core 2, dunno about upstream selinux policy packages - this is from stock FC2 /etc/security/selinux/src/policy/file_contexts/program/rpm.fc: /usr/bin/apt-get -- system_u:object_r:rpm_exec_t /usr/bin/apt-shell -- system_u:object_r:rpm_exec_t /usr/bin/synaptic -- system_u:object_r:rpm_exec_t
The context is not the problem. I'm running the targeted policy from FCdev, which makes both /bin/rpm and /usr/bin/apt* system_u:object_r:bin_t. rpm works fine, however, whereas apt-get does not.
It isn't just a policy issue; rpm had to be modified for SELinux to set file security contexts when creating files. Those changes are in the upstream rpm, and yum seems to work as expected when updating.
I believe apt needs similar modifications. The attached patch to apt fixes the problem for me. I'm not too familiar with rpm, apt, or selinux internals, so this patch might need some work. I just took the code from rpm's lib/rpminstall.c/rpmInstall() function which seemed to be missing in apt's apt-pkg/rpm/rpmpm.cc/pkgRPMLibPM::Process() function.
Had a closer look and the patch indeed seems correct: applied, thanks!
- Panu -
selinux@lists.fedoraproject.org
-
Aleksey Nogin -
Daniel J Walsh -
Gary Peck -
Panu Matilainen -
Stephen Smalley