[libvirt] [PATCH v5 3/3] security_dac: Favour ACLs over chown()

[Michal Privoznik]

On 28.03.2013 10:46, Daniel P. Berrange wrote:
> On Thu, Mar 21, 2013 at 05:50:49PM +0100, Michal Privoznik wrote:
>>  #define VIR_FROM_THIS VIR_FROM_SECURITY
>>  #define SECURITY_DAC_NAME "dac"
>> +#define SECURITY_DAC_XATTR_OLD_ACL "trusted.libvirt.dac.oldACL"
>> +#define SECURITY_DAC_XATTR_OLD_OWNER "trusted.libvirt.dac.oldOwner"
>> +#define SECURITY_DAC_XATTR_REFCOUNT "trusted.libvirt.dac.refCount"
> 
> IMHO we don't need the 'trusted.' prefix on these.
> 
> Daniel
> 

An XATTR has to have a prefix. We can choose from several prefixes.
attr(5) says:

  Currently the security, system, trusted, and user extended attribute
  classes are defined as described below. Additional classes may be
  added in the future.

security - should be used by kernel security modules, such as Security
Enhanced Linux. As long as libvirt doesn't provide kernel module, we
should not be polluting this prefix.

system - used by the kernel to store system objects such as Access
Control Lists and Capabilities. Again, we are not kernel.

trusted - visible and accessible only to processes that have the
CAP_SYS_ADMIN capability (the super user usually has this capability).
Attributes  in  this  class are used to implement mechanisms in user
space (i.e., outside the kernel) which keep information in extended
attributes to which ordinary processes should not have access.

Note, that the three above can be touched only by root (or
CAP_SYS_ADMIN'ed process).

user -  may be assigned to files and directories for storing arbitrary
additional information such as the mime type, character set or encoding
of a file.

The user. can be manipulated by ordinary user.

My rationale for not allowing ordinary user to play with our XATTRs is
to prevent them chowning to arbitrary user.

Michal