Hello all
i'm wondering what assumptions must be made in order to assure that the domain "domX" is the only subject allowed to access a file with type "typeY" in a system where off-line attacks are possible and an integrity check on files and labels in the overall filesystem is not applicable due to the high performance penalty.
These are the hypothesis i think are required: 1) kernel with SELinux, with policy loading and enforcing mode setting disabled at runtime; 2) there is an integrity system stacked with SELinux which is able to grant/deny access depending on the hash and the label of files (checks will be performed only a subset of files, as described in the following points); 3)"local_login_t" is the only domain allowed to change the process label; 4) every file used by the type "local_login_t" is integrity protected (i need to build a list files used by this process and to specify a valid hash) 5) the regular user which plays with "domX" is mapped with the selinux user "user_t" (probably i need extra assumptions to protect the mapping); 6) "domX_exec_t" is the only entrypoint for "domX"; 7) the label "domX_exec_t" is bound to the executable and its hash (the association is verified at execution time); 8) the transition "user_t -> domX" has been defined when executing a file labeled with "domX_exec_t"; 9) for now i assume that the user root is not involved in this use case; 10) file labelled with "typeY" are protected and the label is bound to the hash (the association will be verified at access time); 11) none subject is authorized to relabelfrom "typeY";
Then when defining the rule: allow domX typeY: file { getattr open read };
can i say that files labelled with typeY can be read only by the process started from the executable labelled with "domX_exec_t"?
Thanks in advance for replies
On 02/19/2010 03:37 PM, Roberto Sassu wrote:
Hello all
i'm wondering what assumptions must be made in order to assure that the domain "domX" is the only subject allowed to access a file with type "typeY" in a system where off-line attacks are possible and an integrity check on files and labels in the overall filesystem is not applicable due to the high performance penalty.
These are the hypothesis i think are required:
- kernel with SELinux, with policy loading and enforcing mode setting
disabled at runtime; 2) there is an integrity system stacked with SELinux which is able to grant/deny access depending on the hash and the label of files (checks will be performed only a subset of files, as described in the following points); 3)"local_login_t" is the only domain allowed to change the process label; 4) every file used by the type "local_login_t" is integrity protected (i need to build a list files used by this process and to specify a valid hash) 5) the regular user which plays with "domX" is mapped with the selinux user "user_t" (probably i need extra assumptions to protect the mapping); 6) "domX_exec_t" is the only entrypoint for "domX"; 7) the label "domX_exec_t" is bound to the executable and its hash (the association is verified at execution time); 8) the transition "user_t -> domX" has been defined when executing a file labeled with "domX_exec_t"; 9) for now i assume that the user root is not involved in this use case; 10) file labelled with "typeY" are protected and the label is bound to the hash (the association will be verified at access time); 11) none subject is authorized to relabelfrom "typeY";
Then when defining the rule: allow domX typeY: file { getattr open read };
type typeY; fs_associate(typeY)
If you use above to declare/make usable your type than nothing has access to it (i believe).
Now you can define rules to allow access to the type.
if you declare/make usable typeY as below:
type typeY; files_type(typeY)
Than the file_type attribute is assigned to your typeY.
Some processes have access to the file_type attribute thus typeY in example above.
can i say that files labelled with typeY can be read only by the process started from the executable labelled with "domX_exec_t"?
Thanks in advance for replies
-- selinux mailing list selinux@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/selinux
selinux@lists.fedoraproject.org
-
Dominick Grift -
Roberto Sassu