Re: Denied { search } mingetty and can't log in

[Emeric Maschino]

Hi,

>  Just to let you know that the above AVCs have been reported as bug
>  #178747, #178748, #178789, #178750 and #178753. It seems they're all due
>  to an ia64 specific issue (details in bug #178747). I don't know if my
>  original problem in enforcing mode with mingetty is also concerned by
>  this issue. Today kernel should provide a workaround for the AVCs in
>  permissive mode. I'll test it and let you know the result. 
With kernel 2.6.15-1.1878_FC5, execmod checks are disabled, so I'm no
more getting the corresponding AVCs. Furthermore, I'm now able to start
in enforcing mode (the problem with mingetty was also solved). However,
from the audit.log file, I'm still getting denied read and search AVCs,
mainly due to irqbalance and hald:

type=AVC msg=audit(1138388575.636:9): avc:  denied  { read } for
pid=1946 comm="irqbalance" name="mtab" dev=dm-0 ino=1899143
scontext=system_u:system_r:irqbalance_t:s0
tcontext=system_u:object_r:etc_runtime_t:s0 tclass=file
type=SYSCALL msg=audit(1138388575.636:9): arch=c0000032 syscall=1028
success=no
exit=13 a0=20000008002ae8d0 a1=0 a2=1b6 a3=558281 items=1 pid=1946
auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0
comm="irqbalance" exe="/usr/sbin/irqbalance"

type=AVC msg=audit(1138388575.636:10): avc:  denied  { read } for
pid=1946 comm="irqbalance" name="fstab" dev=dm-0 ino=1901326
scontext=system_u:system_r:irqbalance_t:s0
tcontext=system_u:object_r:etc_t:s0 tclass=file
type=SYSCALL msg=audit(1138388575.636:10): arch=c0000032 syscall=1028
success=no exit=13 a0=20000008002ae938 a1=0 a2=1b6 a3=558281 items=1
pid=1946 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0
fsgid=0 comm="irqbalance" exe="/usr/sbin/irqbalance"

type=AVC msg=audit(1138385008.409:11): avc:  denied  { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir

type=AVC msg=audit(1138385008.477:12): avc:  denied  { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir

type=AVC msg=audit(1138385008.593:13): avc:  denied  { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir

type=AVC msg=audit(1138385008.677:14): avc:  denied  { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir

type=AVC msg=audit(1138385008.733:15): avc:  denied  { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir

type=AVC msg=audit(1138385012.697:17): avc:  denied  { search } for
pid=2383 comm="hald" name="boot" dev=dm-0 ino=13618177
scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:boot_t:s0 tclass=dir

Cheers,

	M

Denied { search } mingetty and can't log in

[Emeric Maschino]

Hi,

>  With kernel 2.6.15-1.1878_FC5, execmod checks are disabled, so
> I'm no
>  more getting the corresponding AVCs. Furthermore, I'm now able to start
>  in enforcing mode (the problem with mingetty was also solved). However,
>  from the audit.log file, I'm still getting denied read and search AVCs,
>  mainly due to irqbalance and hald: 
Just to inform you that these AVCs have been corrected in selinux-
policy-targeted 2.2.9-1. But new hid2hci denied read and write AVCs have
appeared. The never-ending game ;-)

Cheers,

	Émeric

Denied { search } mingetty and can't log in

[Ivan Gyurdiev]

>  Just to inform you that these AVCs have been corrected in selinux-
>  policy-targeted 2.2.9-1. But new hid2hci denied read and write AVCs have
>  appeared. The never-ending game ;-)
>     
There is no way for this game to end...  Not until software developers 
take over the task of writing policy themselves.

I know Dan disagrees with me on this, but I think that this is the only 
way for selinux to be really accepted into the mainstream. First, 
however, more infrastructure is needed to make this possible. Modular 
policy is a step in the right direction. I see that the current strict 
policy is now modular, and that's good news...

Denied { search } mingetty and can't log in

[Daniel J Walsh]

Ivan Gyurdiev wrote:
> >
> > Just to inform you that these AVCs have been corrected in selinux-
> > policy-targeted 2.2.9-1. But new hid2hci denied read and write AVCs have
> > appeared. The never-ending game ;-)
> >   
>  There is no way for this game to end...  Not until software developers 
>  take over the task of writing policy themselves.
>  
Hopefully after we release FC5 the number of AVC will decrease steadily 
as they did in FC3/FC4.  The problem now is the volume of change in 
rawhide and the number of people testing it have not revealed all of the 
problems.  Keep submitting the AVC's, or even better patches and we will 
keep updating policy.
>  I know Dan disagrees with me on this, but I think that this is the 
>  only way for selinux to be really accepted into the mainstream.t 
I don't
disagree with you,  I would love to have the applications 
developers to take over the maintenance of policy for their 
applications.  The problem is the developers have different goals then 
people concerned with security.  They want their applications to run, 
and might take short cuts with security policy.  So if they come up 
against an execmem failure or the inability to read /etc/shadow.  Would 
they redesign the application or just write policy to allow them to do 
the task they want to do.
>  First, however, more infrastructure is needed to make this possible.
>
>  Modular policy is a step in the right direction. I see that the 
>  current strict policy is now modular, and that's good news... 
Loadable Modules
is the first step.  Now we need tools to allow them to 
write the policy more easily.  The current audit2allow allows them to 
build a policy module out of AVC messages,  a step forward would be to 
add some kind of pattern matching to the tool to figure out what file 
contexts it might need.  IE the domain wants to write to var_run, so it 
probably needs to use the pid functions in reference policy.  I know 
Mitre/Tresys are looking into tools to make this easier.
>  -- 
>  fedora-selinux-list mailing list
>  fedora-selinux-list(a)redhat.com
>  https://www.redhat.com/mailman/listinfo/fedora-selinux-list