1105 fails to boot....

[Tom London]

Running strict/enforcing, latest rawhide:

After installing latest packages, relabeling /etc, /bin, /lib, ....
and rebooting, the system produces lots of udev type errors
(cannot remove /dev/.udev_tdb/classSTUFF) and hangs
on 'adding hardware'

Boots (with messages) in permissive mode.

Here are the 'early' AVCs:
Jan 21 07:24:30 fedora kernel: SELinux: initialized (dev bdev, type
bdev), uses genfs_contexts
Jan 21 07:24:30 fedora kernel: SELinux: initialized (dev rootfs, type
rootfs), uses genfs_contexts
Jan 21 07:24:30 fedora kernel: SELinux: initialized (dev sysfs, type
sysfs), uses genfs_contexts
Jan 21 07:24:30 fedora kernel: audit(1106292231.919:0): avc:  denied 
{ read } for  pid=478 exe=/bin/hostname path=/init dev=rootfs ino=17
scontext=system_u:system_r:hostname_t
tcontext=system_u:object_r:root_t tclass=file
Jan 21 07:24:30 fedora kernel: SELinux: initialized (dev usbfs, type
usbfs), uses genfs_contexts
Jan 21 07:24:30 fedora kernel: audit(1106292233.809:0): avc:  denied 
{ read } for  pid=576 exe=/sbin/restorecon path=/init dev=rootfs
ino=17 scontext=system_u:system_r:restorecon_t
tcontext=system_u:object_r:root_t tclass=file
Jan 21 07:24:30 fedora kernel: audit(1106292234.081:0): avc:  denied 
{ read } for  pid=576 exe=/sbin/restorecon name=customizable_types
dev=hda2 ino=4506184 scontext=system_u:system_r:restorecon_t
tcontext=system_u:object_r:default_context_t tclass=file
Jan 21 07:24:30 fedora kernel: audit(1106292235.062:0): avc:  denied 
{ use } for  pid=702 exe=/bin/dmesg path=/init dev=rootfs ino=17
scontext=system_u:system_r:dmesg_t tcontext=system_u:system_r:kernel_t
tclass=fd
Jan 21 07:24:30 fedora kernel: audit(1106292235.062:0): avc:  denied 
{ read } for  pid=702 exe=/bin/dmesg path=/init dev=rootfs ino=17
scontext=system_u:system_r:dmesg_t tcontext=system_u:object_r:root_t
tclass=file
Jan 21 07:24:30 fedora kernel: audit(1106292235.086:0): avc:  denied 
{ read } for  pid=703 exe=/bin/bash path=/init dev=rootfs ino=17
scontext=system_u:system_r:udev_t tcontext=system_u:object_r:root_t
tclass=file
Jan 21 07:24:30 fedora kernel: audit(1106292239.427:0): avc:  denied 
{ use } for  pid=1233 exe=/sbin/kmodule path=/init dev=rootfs ino=17
scontext=system_u:system_r:kudzu_t tcontext=system_u:system_r:kernel_t
tclass=fd
Jan 21 07:24:30 fedora kernel: audit(1106292239.428:0): avc:  denied 
{ read } for  pid=1233 exe=/sbin/kmodule path=/init dev=rootfs ino=17
scontext=system_u:system_r:kudzu_t tcontext=system_u:object_r:root_t
tclass=file
Jan 21 07:24:30 fedora ptal-mlcd: SYSLOG at ExMgr.cpp:652,
dev=mlc:usb:PSC_900_Series, pid=2629, e=2, t=1106321070        
ptal-mlcd successfully initialized.
Jan 21 07:24:30 fedora ptal-printd:
ptal-printd(mlc:usb:PSC_900_Series) successfully initialized using
/var/run/ptal-printd/mlc_usb_PSC_900_Series*.
Jan 21 07:24:30 fedora kernel: Floppy drive(s): fd0 is 1.44M

I'll probe a bit, but any help is welcome!

tom

[Tom London]

On Fri, 21 Jan 2005 07:38:15 -0800, Tom London  wrote:
> Running strict/enforcing, latest rawhide:
>
> After installing latest packages, relabeling /etc, /bin, /lib, ....
> and rebooting, the system produces lots of udev type errors
> (cannot remove /dev/.udev_tdb/classSTUFF) and hangs
> on 'adding hardware'
>
> Boots (with messages) in permissive mode.
>
> I'll probe a bit, but any help is welcome!

OK. Doing the obvious (i.e. adding all of the following) fixes the problem:
allow dmesg_t kernel_t:fd use;
allow dmesg_t root_t:file read;
allow hostname_t root_t:file read;
allow kudzu_t kernel_t:fd use;
allow kudzu_t root_t:file read;
allow restorecon_t default_context_t:file read;
allow restorecon_t root_t:file read;
allow udev_t root_t:file read;

Adding 'root_t' to { kudzu_t restorecon_t udev_t } a problem?

tom

[Stephen Smalley]

On Fri, 2005-01-21 at 10:38, Tom London wrote:
> Jan 21 07:24:30 fedora kernel: audit(1106292231.919:0): avc:  denied 
> { read } for  pid=478 exe=/bin/hostname path=/init dev=rootfs ino=17
> scontext=system_u:system_r:hostname_t
> tcontext=system_u:object_r:root_t tclass=file

I think that this denial reflects a kernel bug - leaking a descriptor to
the rootfs to userspace.  Shouldn't interfere with booting.
> Jan 21 07:24:30 fedora kernel: audit(1106292234.081:0): avc:  denied 
> { read } for  pid=576 exe=/sbin/restorecon name=customizable_types
> dev=hda2 ino=4506184 scontext=system_u:system_r:restorecon_t
> tcontext=system_u:object_r:default_context_t tclass=file

This is more likely the culprit.  restorecon is now trying to read the
customizable_types file to identify contexts that it shouldn't try to
relabel, but if it lacks permission to do so, then the current code is
going to prevent relabeling anything, as it is merely checking for a
non-zero return from is_context_customizable(), which could be an
error.  Fix is to allow access by restorecon_t and setfiles_t, but also
likely change the calling code to distinguish the error case from > 0
case.

[Daniel J Walsh]

Stephen Smalley wrote:
> On Fri, 2005-01-21 at 10:38, Tom London wrote:
> > Jan 21 07:24:30 fedora kernel: audit(1106292231.919:0): avc:  denied 
> > { read } for  pid=478 exe=/bin/hostname path=/init dev=rootfs ino=17
> > scontext=system_u:system_r:hostname_t
> > tcontext=system_u:object_r:root_t tclass=file
>
> I think that this denial reflects a kernel bug - leaking a descriptor to
> the rootfs to userspace.  Shouldn't interfere with booting.
> > Jan 21 07:24:30 fedora kernel: audit(1106292234.081:0): avc:  denied 
> > { read } for  pid=576 exe=/sbin/restorecon name=customizable_types
> > dev=hda2 ino=4506184 scontext=system_u:system_r:restorecon_t
> > tcontext=system_u:object_r:default_context_t tclass=file
>
> This is more likely the culprit.  restorecon is now trying to read the
> customizable_types file to identify contexts that it shouldn't try to
> relabel, but if it lacks permission to do so, then the current code is
> going to prevent relabeling anything, as it is merely checking for a
> non-zero return from is_context_customizable(), which could be an
> error.  Fix is to allow access by restorecon_t and setfiles_t, but also
> likely change the calling code to distinguish the error case from > 0
> case.

Fix in selinux-policy-*-1.21.2-7

FC4 update and SELINUX

[Richard Irving]

I seem to remember an email passing this way
that the latest FC4 targeted update,
nagios stopped working.

I recall the response was
"setenforce permissive, and capture
the audit trail"... or something of that nature.

Can anyone help refresh my memory ?

As, I just got around to testing FC4 on an AMD64,
with it set to "permissive" it -all- works..
with NO AVC messages...

and with it set to "enforcing", it stops
working ...
with NO AVC messages.

I tried "audit2allow -i /dev/null",
but for some reason, that doesn't help me write policy.

:-P

Anyone have more informative output, or subtle clues ?

:-\

TIA!

FC4 update and SELINUX

[Stephen Smalley]

On Mon, 2005-11-07 at 14:53 -0500, Richard Irving wrote:
> As, I just got around to testing FC4 on an AMD64,
> with it set to "permissive" it -all- works..
> with NO AVC messages...
>
> and with it set to "enforcing", it stops
> working ...
> with NO AVC messages.

If there are truly no audit messages (in /var/log/audit/audit.log), then
install selinux-policy-targeted-sources if you don't already have them,
and then do:
cd /etc/selinux/targeted/src/policy
make clean enableaudit load
<run your tests>
cd /etc/selinux/targeted/src/policy
make clean load

Then look again at audit.log.

FC4 update and SELINUX

[Richard Irving]

Stephen Smalley wrote:
> On Mon, 2005-11-07 at 14:53 -0500, Richard Irving wrote:
> > As, I just got around to testing FC4 on an AMD64,
> > with it set to "permissive" it -all- works..
> > with NO AVC messages...
> >
> > and with it set to "enforcing", it stops
> > working ...
> > with NO AVC messages.

Dohh... FC3 to FC4  "OHS".

Why is the problem always the loose
nut in front of the keyboard ?

:-)

Thanks All!
> If there are truly no audit messages (in /var/log/audit/audit.log), then
> install selinux-policy-targeted-sources if you don't already have them,
> and then do:
> cd /etc/selinux/targeted/src/policy
> make clean enableaudit load
>
> <run your tests>
> cd /etc/selinux/targeted/src/policy
> make clean load
>
> Then look again at audit.log.

FC4 update and SELINUX

[Daniel J Walsh]

Richard Irving wrote:
> I seem to remember an email passing this way
> that the latest FC4 targeted update,
> nagios stopped working.
>
> I recall the response was
> "setenforce permissive, and capture
> the audit trail"... or something of that nature.
>
> Can anyone help refresh my memory ?
>
> As, I just got around to testing FC4 on an AMD64,
> with it set to "permissive" it -all- works..
> with NO AVC messages...

Are you looking in /var/log/audit/audit.log for avcs?

You can turn off all the dontaudit rules by installing 
selinux-policy-targeted-source
cd /etc/selinux/targeted/src/policy
make enableaudit; make load

make clean; make load will set it back.
> and with it set to "enforcing", it stops
> working ...
> with NO AVC messages.
>
> I tried "audit2allow -i /dev/null",
> but for some reason, that doesn't help me write policy.
>
> :-P
>
> Anyone have more informative output, or subtle clues ?
>
> :-\
>
> TIA!
>
> -- 
> fedora-selinux-list mailing list
> [e-mail]
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list