ima-appraisal: CAP_MAC_ADMIN w/SELinux

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



I'm seeing some interesting behavior in ima_inode_setxattr() with an
SELinux targeted policy enabled. Unlike the definition for
CAP_SYS_ADMIN, CAP_MAC_ADMIN does not permit root to write extended
attributes. (Without SELinux enabled, root can write 'security.ima'.)
Is this the intended behavior?

Without this permission, restorecond is also unable to write extended
attributes. 

kernel: type=1400 audit(1279830569.844:4): avc:  denied  { mac_admin }
for  pid=447 comm="restorecon" capability=33
scontext=system_u:system_r:setfiles_t:s0
tcontext=system_u:system_r:setfiles_t:s0 tclass=capability2

/*
* ima_protect_xattr - protect 'security.ima'
*
* Ensure that not just anyone can modify or remove 'security.ima'.
*/
int ima_protect_xattr(struct dentry *dentry, const char *xattr_name,
                      const void *xattr_value, size_t xattr_value_len)
{
        if ((strcmp(xattr_name, XATTR_NAME_IMA) == 0)
            && !capable(CAP_MAC_ADMIN))
                return -EPERM;
        return 0;
}

Adding the following rules, permits root and restorecond to write
'security.ima'. 

module local-cap 1.0;

require {
	type setfiles_t;
	type unconfined_t;
	class capability2 mac_admin;
}

#============= setfiles_t ==============
allow setfiles_t self:capability2 mac_admin;
allow unconfined_t self:capability2 mac_admin;

thanks,

Mimi




--
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.


[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux