10:27 p.m.
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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
10:21 a.m.
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?
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
10:41 a.m.
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
12:18 a.m.
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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
12:38 a.m.
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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
12:57 a.m.
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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
1:05 a.m.
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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
1:14 a.m.
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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
9:18 a.m.
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.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
1:21 a.m.
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
http://www.ocf.berkeley.edu/~bobk/garnome
7:10 a.m.
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
2:07 p.m.
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
--
Bob Kashani
http://www.ocf.berkeley.edu/~bobk/garnome
7:13 a.m.
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 <sds(a)epoch.ncsc.mil>
National Security Agency
9:14 a.m.
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 <sds(a)epoch.ncsc.mil>
National Security Agency
9:16 a.m.
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.
2:31 p.m.
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.
2:33 p.m.
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
http://www.ocf.berkeley.edu/~bobk/garnome
2:53 p.m.
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
7047
days inactive
7055
days old
selinux@lists.fedoraproject.org
17 comments
4 participants
participants (4)
-
Bob Kashani -
Daniel J Walsh -
Paul Nasrat -
Stephen Smalley