[refpolicy3 RFC] Split broad file contexts

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

 



In refpolicy2, we have several types, such as bin_t, that have file contexts related to other modules, e.g.:

/etc/acpi/actions(/.*)?			gen_context(system_u:object_r:bin_t,s0)

/usr/lib/mailman/bin(/.*)?		gen_context(system_u:object_r:bin_t,s0)

/var/mailman/bin(/.*)?			gen_context(system_u:object_r:bin_t,s0)


relate to acpi and mailman.

Should we continue to put all of the bin_t labeling in files.cas or should we split it back to the individual modules? This was originally done in refpolicy2 so users could look in a single place for everything about bin_t for encapsulation. This is nice for users, but not so nice for maintenance and version control.

Since cascade has the "extend" feature, we can split up the labeling among relevant modules, and tooling can construct a single unified view of the file contexts of bin_t and the like.

For example, instead of this in file.cas:

resource bin_t inherits executable {
  ...many fcs...
  file_context(/etc/acpi/actions(/.*)?, any);
}

we have this in acpi.cas:

extend bin_t {
  file_context(/etc/acpi/actions(/.*)?, any);
}


Thoughts?


--
Chris PeBenito



[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux