Jaejyn Shin wrote:
Dear SEAndroid developers.
I found following unconfined domains in the aosp mater source.
init_shell.te:6:unconfined_domain(init_shell)
init.te:4:unconfined_domain(init)
kernel.te:7:unconfined_domain(kernel)
recovery.te:4:unconfined_domain(recovery)
su.te:16: unconfined_domain(su) -> su is unconfined only in
userdebug_or_eng
I think that all domain should not be unconfined domain to be more secure.
What does "more secure" mean? "Secure" isn't a goal that you can attain.
There are specific threats that you need to understand, which is your
threat model, and there are mitigations against those threats, which is
your security model.
What do you gain by making kernel not unconfined, for example? You may
catch bugs where the kernel enforces the policy and possibly doesn't do
something it shouldn't have, but that has nothing to do with the threat
model.
There are many improvements that can be made to the AOSP policies, and
Stephen is doing a tremendous job of improving them, but grepping
through policicies for unconfined and somehow determining that there is
a security issue is not helpful.
Try to understand the security model being implemented, then look at the
policies for specific issues that undermine that security model (using
tools like apol are a huge help here).
As an example, we don't want malicious (untrusted) apps to write to high
integrity files. High integrity files are those that are consumed by the
base system and system services. Things like system_data_file are high
integrity. A valid issue for the policy might be if untrusted_app could
write to system_data_file.
So, use a tool like sesearch to see if that is a problem (this is
against a random policy I had laying around):
$ sesearch --allow -s untrusted_app -t system_data_file -p write sepolicy
Found 1 semantic av rules:
allow untrusteddomain system_data_file : sock_file { ioctl read
write getattr lock append open } ;
That may or may not be an issue, we'll have to look at how sock_files
labeled system_data_file are used.
Hopefully you get the point. The quality of the policy is much more
nuanced than what domains are unconfined.
Is there specific reason to remain those domains as the "unconfined" ?
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
