neverallow untrusted_app as a mlstrustedsubject.
Assigning mlstrustedsubject to untrusted_app would undermine the per-user isolation model being enforced via levelFrom=user in seapp_contexts and the mls constraints. There is no direct way to specify a neverallow on attribute assignment, but this makes use of a particular property of the fork permission to prevent ever adding mlstrustedsubject to untrusted_app. A similar restriction for app_data_file and mlstrustedobject is also important for the same reason, but cannot be expressed as a neverallow. Change-Id: I5170cadc55cc614aef0cd5f6491de8f69a4fa2a0 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This commit is contained in:
parent
b8caf7fdd4
commit
eaece936f2
1 changed files with 10 additions and 0 deletions
|
@ -166,3 +166,13 @@ neverallow untrusted_app service_manager_type:service_manager add;
|
|||
neverallow untrusted_app property_socket:sock_file write;
|
||||
neverallow untrusted_app init:unix_stream_socket connectto;
|
||||
neverallow untrusted_app property_type:property_service set;
|
||||
|
||||
# Do not allow untrusted_app to be assigned mlstrustedsubject.
|
||||
# This would undermine the per-user isolation model being
|
||||
# enforced via levelFrom=user in seapp_contexts and the mls
|
||||
# constraints. As there is no direct way to specify a neverallow
|
||||
# on attribute assignment, this relies on the fact that fork
|
||||
# permission only makes sense within a domain (hence should
|
||||
# never be granted to any other domain within mlstrustedsubject)
|
||||
# and untrusted_app is allowed fork permission to itself.
|
||||
neverallow untrusted_app mlstrustedsubject:process fork;
|
||||
|
|
Loading…
Reference in a new issue