11:48 a.m.
Hi,
I just updated from rawhide. I am using selinux-policy-targeted-1.19.15-7. It
breaks about everything. My suggestion is to skip it (unless you want a little
excitement in your life).
You cannot even get in via ssh to correct the problem because of ssh not being
able to execute bash. Relabeling does not fix it. If its too late, your only hope
is setting selinux=0 at boot menu and waiting for a corrected selinux targeted
policy unless you have the old one.
-Steve Grubb
__________________________________
Do you Yahoo!?
Yahoo! Mail - 250MB free storage. Do more. Manage less.
http://info.mail.yahoo.com/mail_250
12:09 p.m.
On Fri, 2004-12-24 at 09:48 -0800, Steve G wrote:
You cannot even get in via ssh to correct the problem because of ssh
not being
able to execute bash. Relabeling does not fix it. If its too late, your only hope
is setting selinux=0 at boot menu and waiting for a corrected selinux targeted
policy unless you have the old one.
Suggest setting SELINUX=permissive in /etc/sysconfig/selinux instead
so that contexts still get set properly (relatively speaking) for when
the targeted policy is fixed.
12:41 p.m.
Suggest setting SELINUX=permissive in /etc/sysconfig/selinux instead
so that contexts still get set properly (relatively speaking) for when
the targeted policy is fixed
You are right. But I was thinking of the person discovering that they've fell
into this hole. When you are at the gdm prompt trying to login, your only way of
getting in is disabling selinux on the command prompt, boot up, then set it to
permissive, and reboot.
BTW, this is all that's in the logs:
Dec 24 12:45:24 localhost gdm[2549]: session_child_run: Could not exec
/etc/X11/xdm/Xsession default
There is no avc messages or anything useful.
Also, selinux-policy-targeted-1.19.15-5 works fine. Its something in the last day
that causes this.
-Steve Grubb
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
12:42 p.m.
Hi,
I just updated from rawhide. I am using
selinux-policy-targeted-1.19.15-7. It
breaks about everything. My suggestion is to skip it (unless you want a little
excitement in your life).
glibc is also knackered (fails to map correctly).
I've reverted back to the previous version of both.
TTFN
Paul
--
"He's not the Messiah, he's a very naughty boy!"
- Life of Brian, Monty Python
1:46 p.m.
Suggest setting SELINUX=permissive in /etc/sysconfig/selinux instead
so that contexts still get set properly (relatively speaking) for when
the targeted policy is fixed
You are right. But I was thinking of the person discovering that they've fell
into this hole. When you are at the gdm prompt trying to login, your only way of
getting in is disabling selinux on the command prompt, boot up, then set it to
permissive, and reboot.
BTW, this is all that's in the logs:
Dec 24 12:45:24 localhost gdm[2549]: session_child_run: Could not exec
/etc/X11/xdm/Xsession default
There is no avc messages or anything useful.
Also, selinux-policy-targeted-1.19.15-5 works fine. Its something in the last day
that causes this.
-Steve Grubb
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
2:19 p.m.
Paul wrote:
>I just updated from rawhide. I am using
selinux-policy-targeted-1.19.15-7. It
>breaks about everything. My suggestion is to skip it (unless you want a little
>excitement in your life).
glibc is also knackered (fails to map correctly).
That is extremely unlikely, especially since I run it (and the latest
policy as well).
Since nobody has posted any actual information I must guess that some
files are mislabeled. E.g., ldconfig for some reason creates updated
glibc DOSs with
system_u:object_r:lib_t
instead of
system_u:object_r:shlib_t
This difference is crucial since the policy now is restrictive when it
comes to mapping files for execution. So, take a look at the output of
ls -lZ /lib /lib/tls /usr/lib
(and for related directories). If any DSO uses lib_t instead of
shlib_t, fix the label. The easiest way to do this is to relabel the
entire filesystem. More info at
http://fedora.redhat.com/docs/selinux-faq-fc3/
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
2:52 p.m.
> glibc is also knackered (fails to map correctly).
That is extremely unlikely, especially since I run it (and the latest
policy as well).
I'm also running glibc-2.3.4-3 and haven't seen any glibc problems.
wrt the original problem, I reverted back to targeted 1.19.15-5 and the problem
is still there. There must be another update that caused the problem...but
interestingly, turning off selinux allows me to log in.
I also changed the system to boot to run level 3. From there, if I startx
everything is OK. But if I do init 5 and then try to log in it doesn't let me.
Also found the lack of avc messages may be because the audit deamon got 'em.
There's about 600k lines of messages I'm sorting through. I think I'll delete
them and start over...
-Steve Grubb
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
3:18 p.m.
On Fri, 2004-12-24 at 12:19 -0800, Ulrich Drepper wrote:
Paul wrote:
> glibc is also knackered (fails to map correctly).
That is extremely unlikely, especially since I run it (and the latest
policy as well).
Since nobody has posted any actual information I must guess that some
files are mislabeled. E.g., ldconfig for some reason creates updated
glibc DOSs with
system_u:object_r:lib_t
instead of
system_u:object_r:shlib_t
This difference is crucial since the policy now is restrictive when it
comes to mapping files for execution. So, take a look at the output of
ls -lZ /lib /lib/tls /usr/lib
(and for related directories). If any DSO uses lib_t instead of
shlib_t, fix the label. The easiest way to do this is to relabel the
entire filesystem. More info at
Except for one thing. At least in my case, I *have* relabeled the
filesystem. Twice. But since you asked, here is some actual
information:
===
ws187:root:493)# slogin iadonisi@ws187
iadonisi@ws187's password:
Last login: Fri Dec 24 15:58:18 2004 from ws187.local.linuxlobbyist.org
audit(1103921912.627:0): avc: denied { transition } for pid=5909
exe=/usr/sbin/sshd path=/bin/bash dev=dm-0 ino=588724
scontext=root:system_r:initrc_t tcontext=user_u:system_r:unconfined_t
tclass=process
/bin/bash: Permission denied
Connection to ws187 closed.
ws187:root:494)#
===
And even after relabeling, ls -lZ does in fact show DSOs with lib_t
instead of shlib_t. I could try relabeling these DSOs manually, though
it does make me a little nervous, but it does seem to indicate there
might something wrong with selinux-policy-targeted.
FYI, this is a fully updated rawhide system, minus the swig and xfce4
packages due to some dependency problems.
--
-Paul Iadonisi
Senior System Administrator
Red Hat Certified Engineer / Local Linux Lobbyist
Ever see a penguin fly? -- Try Linux.
GPL all the way: Sell services, don't lease secrets
3:28 p.m.
There is no avc messages or anything useful.
OK here's what I pulled from the audit log:
event={'msg_type'=KERNEL 'seq'=0 'len'=222
'message'='audit(1103922269.990:3027786): avc: denied { entrypoint } for
pid=3176 exe=/usr/bin/gdm-binary path=/etc/X11/xdm/Xsession dev=hda2 ino=214827
scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:etc_t tclass=file' }
event={'msg_type'=KERNEL 'seq'=0 'len'=87
'message'='audit(1103922269.990:3027786): item=0 name=/etc/X11/xdm/Xsession
inode=214827 dev=00:00gdm-binary path=/etc/X11/xdm/Xsession dev=hda2 ino=214827
scontext=user_u:system_r:httpd_t tcontext=system_u:object_r:etc_t tclass=file' }
I'm wondering where the httpd_t comes from? I've relabeled the system a couple of
times. BTW, cups is just scrolling avc denied messages:
event={'msg_type'=KERNEL 'seq'=0 'len'=194
'message'='audit(1103922414.543:809779): avc: denied { unlink } for
pid=1849
exe=/usr/sbin/cupsd name=0 dev=hda2 ino=212999 scontext=user_u:system_r:cupsd_t
tcontext=system_u:object_r:file_t tclass=file' }
-Steve Grubb
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
5:19 p.m.
Hi,
>>I just updated from rawhide. I am using
selinux-policy-targeted-1.19.15-7. It
>>breaks about everything. My suggestion is to skip it (unless you want a little
>>excitement in your life).
>
>
> glibc is also knackered (fails to map correctly).
That is extremely unlikely, especially since I run it (and the latest
policy as well).
Since nobody has posted any actual information I must guess that some
files are mislabeled. E.g., ldconfig for some reason creates updated
glibc DOSs with
From rom memory (I know, I should have noted it down), libdl.so.2 was at
fault with some error about it not being able to map correctly. Meant
that httpd, cups and a few other services would fail to work.
Reverting back to 2.3.3-99 on glibc and the previous selinux fixed the
problems.
TTFN
Paul
--
"He's not the Messiah, he's a very naughty boy!"
- Life of Brian, Monty Python
7:23 a.m.
On Fri, 2004-12-24 at 15:19, Ulrich Drepper wrote:
Since nobody has posted any actual information I must guess that some
files are mislabeled. E.g., ldconfig for some reason creates updated
glibc DOSs with
system_u:object_r:lib_t
instead of
system_u:object_r:shlib_t
Sorry, ldconfig regenerates the DSOs, not just the links and cache? If
so, then it needs a patch to preserve the types on the DSOs.
--
Stephen Smalley <sds(a)epoch.ncsc.mil>
National Security Agency
7059
days inactive
7062
days old
11 comments
5 participants
participants (5)
-
Paul F. Johnson -
Paul Iadonisi -
Stephen Smalley -
Steve G -
Ulrich Drepper