On 02/13/2013 08:42 AM, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
This causes SELinux to have a bad name, and we really need to cleanup the
kernel to make sure MAC Checks happen after DAC Checks.
Here is an example, of a UID running a program that attempts to create a file
in a directory which would be denied by dac.
type=PATH msg=audit(02/12/13 05:53:32.462:691259) : item=0
name=/var/run/netreport/3243 inode=258591 dev=ca:42 mode=dir,775 ouid=root
ogid=root rdev=00:00 obj=system_u:object_r:var_run_t:s0
type=CWD msg=audit(02/12/13 05:53:32.462:691259) :
cwd=/var/lib/openshift/c323ad7c3b48426eaa8bb13f4234a5e1/diy-0.1/logs
type=SYSCALL msg=audit(02/12/13 05:53:32.462:691259) : arch=x86_64
syscall=open success=no exit=-13(Permission denied) a0=7fff294849b0 a1=202c1
a2=0 a3=d items=1 ppid=3243 pid=12586 auid=c323ad7c3b48426eaa8bb13f4234a5e1
uid=c323ad7c3b48426eaa8bb13f4234a5e1 gid=c323ad7c3b48426eaa8bb13f4234a5e1
euid=c323ad7c3b48426eaa8bb13f4234a5e1 suid=c323ad7c3b48426eaa8bb13f4234a5e1
fsuid=c323ad7c3b48426eaa8bb13f4234a5e1 egid=root sgid=root fsgid=root tty=pts4
ses=37928 comm=netreport exe=/sbin/netreport
subj=unconfined_u:system_r:openshift_t:s0:c5,c283 key=(null)
type=AVC msg=audit(02/12/13 05:53:32.462:691259) : avc: denied { write } for
pid=12586 comm=netreport name=netreport dev=xvde2 ino=258591
scontext=unconfined_u:system_r:openshift_t:s0:c5,c283
tcontext=system_u:object_r:var_run_t:s0 tclass=dir
As a policy writer I either have to add a bogus dontaudit on this or have
customers,
I have seen regularly seen Capability checks, rawip_sockets, mmap_zero etc
that would be blocked by DAC, and yet we generate an ugly MAC AVC.
I realize in some cases we might want to know if users are trying to do evil
things, but almost all cases the user just is executing applications that
generate an AVC for something that without SELinux turned on would have been
Something isn't right here, as the SELinux read/write checks do occur
after the DAC ones (inode_permission). Likewise for capability checks.
setattr is an unusual case due to the fact that the filesystem
implementation combines permission checking and performing the operation
into a single inode operation, so we have to perform our check first if
we want to ensure it happens at all. Socket checks are a layering issue;
LSM/SELinux hooks the generic socket layer, whereas most of the DAC
checks occur down in the network protocol implementations; hard to fix.
mmap_zero was a conscious choice on Eric's part.
But your particular example doesn't make sense unless the process
actually did pass the DAC checks for directory write. Maybe it has the
group in its supplementary group set?
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
