When I run:
yum -y --installroot=/testroot groupinstall "Base"
I get all kinds of errors like this:
error: %post(libuser-0.52.5-1.i386) scriptlet failed, exit status 255 error: %post(gnupg-1.2.6-1.i386) scriptlet failed, exit status 255
If I turn selinux off there are no errors. Any ideas why this is happening?
FC3 fully updated.
yum-2.1.12-0.fc3 libselinux-1.19.1-8 selinux-policy-targeted-1.17.30-2.58
Bob
On Wed, 2004-12-29 at 23:27, Bob Kashani wrote:
When I run:
yum -y --installroot=/testroot groupinstall "Base"
I get all kinds of errors like this:
error: %post(libuser-0.52.5-1.i386) scriptlet failed, exit status 255 error: %post(gnupg-1.2.6-1.i386) scriptlet failed, exit status 255
If I turn selinux off there are no errors. Any ideas why this is happening?
FC3 fully updated.
yum-2.1.12-0.fc3 libselinux-1.19.1-8 selinux-policy-targeted-1.17.30-2.58
What audit messages do you see in /var/log/messages upon attempting this yum install?
On Mon, 2005-01-03 at 11:21 -0500, Stephen Smalley wrote:
What audit messages do you see in /var/log/messages upon attempting this yum install?
I get no audit messages. I tried running tail -f during the install and it logged nothing. I'm assuming that it's not logging anything since it's installing in a chroot and all the commands that are being executed are in the chroot.
Bob
On Mon, 2005-01-03 at 22:18 -0800, Bob Kashani wrote:
On Mon, 2005-01-03 at 11:21 -0500, Stephen Smalley wrote:
What audit messages do you see in /var/log/messages upon attempting this yum install?
I get no audit messages. I tried running tail -f during the install and it logged nothing. I'm assuming that it's not logging anything since it's installing in a chroot and all the commands that are being executed are in the chroot.
Sorry, Stephen!!! I was wrong. I actually do get messages. But Paul's suggestion fixed everything with the exception of these messages:
ls: readlink:: No such file or directory ls: file: No such file or directory ls: expected: No such file or directory
Bob
On Wed, Dec 29, 2004 at 08:27:09PM -0800, Bob Kashani wrote:
When I run:
yum -y --installroot=/testroot groupinstall "Base"
Do you have /selinux /proc and /sys mounted in your chroot?
mount --bind /proc /testroot/proc/ mount --bind /selinux /testroot/selinux/ mount --bind /sys /testroot/sys/
Paul
On Mon, 2005-01-03 at 11:41 -0500, Paul Nasrat wrote:
On Wed, Dec 29, 2004 at 08:27:09PM -0800, Bob Kashani wrote:
When I run:
yum -y --installroot=/testroot groupinstall "Base"
Do you have /selinux /proc and /sys mounted in your chroot?
mount --bind /proc /testroot/proc/ mount --bind /selinux /testroot/selinux/ mount --bind /sys /testroot/sys/
Thanks Paul. That was it.
I was only mounting /proc...so when I mounted /selinux & /sys almost all of my errors went away.
The only two errors that I haven't been able to fix are:
/sbin/ldconfig: Can't open configuration file /etc/ld.so.conf: Permission denied /sbin/ldconfig: Can't remove old temporary cache file /etc/ld.so.cache~: Permission denied
and
Installing: kernel 100 % done 101/111 ls: readlink:: No such file or directory ls: file: No such file or directory ls: expected: No such file or directory Installing: selinux-policy-targeted 100 % done 102/111
coreutils and file are being installed early on so readlink and file should be available by the time the kernel is installed. I have no idea what 'expected' is? Is this just some random output since something failed?
Bob
On Mon, 2005-01-03 at 22:38 -0800, Bob Kashani wrote:
/sbin/ldconfig: Can't open configuration file /etc/ld.so.conf: Permission denied /sbin/ldconfig: Can't remove old temporary cache file /etc/ld.so.cache~: Permission denied
Just to clarify...I was running the wrong script when I got these messages. When I install in /testroot I don't get them. But I do get them when I try to install in my home dir. So why does this happen when I try to install in /home and how can I fix it?
and
Installing: kernel 100 % done 101/111 ls: readlink:: No such file or directory ls: file: No such file or directory ls: expected: No such file or directory Installing: selinux-policy-targeted 100 % done 102/111
I still get these messages but I'm not all that concerned about them since I'm not going to be doing anything kernel related in the chroot. But it would be nice to find out what's going on. :)
Bob
On Mon, 2005-01-03 at 23:05 -0800, Bob Kashani wrote:
On Mon, 2005-01-03 at 22:38 -0800, Bob Kashani wrote:
/sbin/ldconfig: Can't open configuration file /etc/ld.so.conf: Permission denied /sbin/ldconfig: Can't remove old temporary cache file /etc/ld.so.cache~: Permission denied
Just to clarify...I was running the wrong script when I got these messages. When I install in /testroot I don't get them. But I do get them when I try to install in my home dir. So why does this happen when I try to install in /home and how can I fix it?
Sorry about all the posts.
But here is the log message that I get when ldconfig fails in /home (as requested by Stephen).
Jan 3 22:44:05 chaucer kernel: audit(1104821045.640:0): avc: denied { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=user_u:object_r:file_t tclass=dir Jan 3 22:44:05 chaucer kernel: audit(1104821045.641:0): avc: denied { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=user_u:object_r:file_t tclass=dir
Bob
On Tue, 2005-01-04 at 02:14, Bob Kashani wrote:
But here is the log message that I get when ldconfig fails in /home (as requested by Stephen).
Jan 3 22:44:05 chaucer kernel: audit(1104821045.640:0): avc: denied { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=user_u:object_r:file_t tclass=dir Jan 3 22:44:05 chaucer kernel: audit(1104821045.641:0): avc: denied { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=user_u:object_r:file_t tclass=dir
First, I'd suggest relabeling /home, as there shouldn't be any file_t files there. restorecon -R /home. Was /home inherited from a prior install, or did you run a non-SELinux kernel while creating files there?
Second, ldconfig is normally restricted in the set of types it can access; see the "SELinux and third party installers" thread. This can be changed in the policy if necesssary, but understand that there are implications.
On Tue, 2005-01-04 at 10:18 -0500, Stephen Smalley wrote:
On Tue, 2005-01-04 at 02:14, Bob Kashani wrote:
But here is the log message that I get when ldconfig fails in /home (as requested by Stephen).
Jan 3 22:44:05 chaucer kernel: audit(1104821045.640:0): avc: denied { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=user_u:object_r:file_t tclass=dir Jan 3 22:44:05 chaucer kernel: audit(1104821045.641:0): avc: denied { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=user_u:object_r:file_t tclass=dir
First, I'd suggest relabeling /home, as there shouldn't be any file_t files there. restorecon -R /home. Was /home inherited from a prior install, or did you run a non-SELinux kernel while creating files there?
Well, /home/gnome (my test user account) is actually a symbolic link to /mnt/hdb1/home/gnome (this way I can log into the same account from rawhide and FC3 without having to copy files around). /home is on hda3 and /home/gnome is on hdb1. hdb1 has rawhide installed on it and I had turned off selinux a long time ago since it was giving me problems. But all of the files in /home/gnome were created under FC3 w/ selinux. I booted into rawhide (hdb1) and enabled selinux and ran 'restorecon - R /'. Now when I'm in FC3 file_t is gone. :)
Second, ldconfig is normally restricted in the set of types it can access; see the "SELinux and third party installers" thread. This can be changed in the policy if necesssary, but understand that there are implications.
I read the thread and I seem to understand the technical reason behind why ldconfig is restricted in the way that it is (the security side of the issue). But is seems a little harsh from a usability point of view since for example, you can no longer run ldconfig in a chroot in your home dir. I like fine grained security but isn't the whole idea behind policy-targeted to enable security without restricting usability too much? I would understand not allowing ldconfig to execute in /home with policy-strict but shouldn't policy-targeted allow you to do this regardless of the potential security issues? Do the security concerns in this case outweigh the usability issues?
Bob
Bob Kashani wrote:
On Tue, 2005-01-04 at 10:18 -0500, Stephen Smalley wrote:
On Tue, 2005-01-04 at 02:14, Bob Kashani wrote:
But here is the log message that I get when ldconfig fails in /home (as requested by Stephen).
Jan 3 22:44:05 chaucer kernel: audit(1104821045.640:0): avc: denied { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=user_u:object_r:file_t tclass=dir Jan 3 22:44:05 chaucer kernel: audit(1104821045.641:0): avc: denied { search } for pid=4960 exe=/sbin/ldconfig name=bob-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=user_u:object_r:file_t tclass=dir
First, I'd suggest relabeling /home, as there shouldn't be any file_t files there. restorecon -R /home. Was /home inherited from a prior install, or did you run a non-SELinux kernel while creating files there?
Well, /home/gnome (my test user account) is actually a symbolic link to /mnt/hdb1/home/gnome (this way I can log into the same account from rawhide and FC3 without having to copy files around). /home is on hda3 and /home/gnome is on hdb1. hdb1 has rawhide installed on it and I had turned off selinux a long time ago since it was giving me problems. But all of the files in /home/gnome were created under FC3 w/ selinux. I booted into rawhide (hdb1) and enabled selinux and ran 'restorecon - R /'. Now when I'm in FC3 file_t is gone. :)
Second, ldconfig is normally restricted in the set of types it can access; see the "SELinux and third party installers" thread. This can be changed in the policy if necesssary, but understand that there are implications.
I read the thread and I seem to understand the technical reason behind why ldconfig is restricted in the way that it is (the security side of the issue). But is seems a little harsh from a usability point of view since for example, you can no longer run ldconfig in a chroot in your home dir. I like fine grained security but isn't the whole idea behind policy-targeted to enable security without restricting usability too much? I would understand not allowing ldconfig to execute in /home with policy-strict but shouldn't policy-targeted allow you to do this regardless of the potential security issues? Do the security concerns in this case outweigh the usability issues?
Bob
What AVC messages are you seeing. We can and probably should loosen up ldconfig policy for targeted.
Dan
On Wed, 2005-01-05 at 08:10 -0500, Daniel J Walsh wrote:
I read the thread and I seem to understand the technical reason behind why ldconfig is restricted in the way that it is (the security side of the issue). But is seems a little harsh from a usability point of view since for example, you can no longer run ldconfig in a chroot in your home dir. I like fine grained security but isn't the whole idea behind policy-targeted to enable security without restricting usability too much? I would understand not allowing ldconfig to execute in /home with policy-strict but shouldn't policy-targeted allow you to do this regardless of the potential security issues? Do the security concerns in this case outweigh the usability issues?
Bob
What AVC messages are you seeing. We can and probably should loosen up ldconfig policy for targeted.
Dan
Here is the AVC message I'm getting:
Jan 5 11:56:39 chaucer kernel: audit(1104954999.233:0): avc: denied { search } for pid=4605 exe=/sbin/ldconfig name=g-chroot dev=hdb1 ino=855792 scontext=root:system_r:ldconfig_t tcontext=system_u:object_r:user_home_t tclass=dir
Bob
On Wed, 2005-01-05 at 02:21, Bob Kashani wrote:
I read the thread and I seem to understand the technical reason behind why ldconfig is restricted in the way that it is (the security side of the issue). But is seems a little harsh from a usability point of view since for example, you can no longer run ldconfig in a chroot in your home dir. I like fine grained security but isn't the whole idea behind policy-targeted to enable security without restricting usability too much? I would understand not allowing ldconfig to execute in /home with policy-strict but shouldn't policy-targeted allow you to do this regardless of the potential security issues? Do the security concerns in this case outweigh the usability issues?
I'm not clear on why ldconfig runs in its own domain at all under targeted policy (vs. unconfined_t). It used to just run unconfined_t in older versions of the targeted policy. Is it an attempt to preserve the type on /etc/ld.so.cache via the file type transition rules?
Stephen Smalley wrote:
On Wed, 2005-01-05 at 02:21, Bob Kashani wrote:
I read the thread and I seem to understand the technical reason behind why ldconfig is restricted in the way that it is (the security side of the issue). But is seems a little harsh from a usability point of view since for example, you can no longer run ldconfig in a chroot in your home dir. I like fine grained security but isn't the whole idea behind policy-targeted to enable security without restricting usability too much? I would understand not allowing ldconfig to execute in /home with policy-strict but shouldn't policy-targeted allow you to do this regardless of the potential security issues? Do the security concerns in this case outweigh the usability issues?
I'm not clear on why ldconfig runs in its own domain at all under targeted policy (vs. unconfined_t). It used to just run unconfined_t in older versions of the targeted policy. Is it an attempt to preserve the type on /etc/ld.so.cache via the file type transition rules?
Yes.
On Thu, 2005-01-06 at 10:16, Daniel J Walsh wrote:
Stephen Smalley wrote:
I'm not clear on why ldconfig runs in its own domain at all under targeted policy (vs. unconfined_t). It used to just run unconfined_t in older versions of the targeted policy. Is it an attempt to preserve the type on /etc/ld.so.cache via the file type transition rules?
Yes.
Ok, so why not just add an unconfined_domain(ldconfig_t) to unconfined.te in the targeted policy, so that ldconfig will still have the file type transition rule but will be unrestricted there.
Stephen Smalley wrote:
On Thu, 2005-01-06 at 10:16, Daniel J Walsh wrote:
Stephen Smalley wrote:
I'm not clear on why ldconfig runs in its own domain at all under targeted policy (vs. unconfined_t). It used to just run unconfined_t in older versions of the targeted policy. Is it an attempt to preserve the type on /etc/ld.so.cache via the file type transition rules?
Yes.
Ok, so why not just add an unconfined_domain(ldconfig_t) to unconfined.te in the targeted policy, so that ldconfig will still have the file type transition rule but will be unrestricted there.
I have done that.
On Thu, 2005-01-06 at 15:31 -0500, Daniel J Walsh wrote:
Ok, so why not just add an unconfined_domain(ldconfig_t) to unconfined.te in the targeted policy, so that ldconfig will still have the file type transition rule but will be unrestricted there.
I have done that.
Thanks guys for fixing this. Any chance this will get backported to FC3?
Bob
Bob Kashani wrote:
On Thu, 2005-01-06 at 15:31 -0500, Daniel J Walsh wrote:
Ok, so why not just add an unconfined_domain(ldconfig_t) to unconfined.te in the targeted policy, so that ldconfig will still have the file type transition rule but will be unrestricted there.
I have done that.
Thanks guys for fixing this. Any chance this will get backported to FC3?
Bob
Yes selinux-policy-targeted-1.17.30-2.68 should be out shortly
selinux@lists.fedoraproject.org
-
Bob Kashani -
Daniel J Walsh -
Paul Nasrat -
Stephen Smalley