On 10/21/2014 08:36 PM, 심현용 wrote:
> Hi, I have some problem in recovery mode.
>
> This is error log.
> <5>[ 6.253512 / 01-01 09:17:40.910] type=1400 audit(33460.910:3): avc:
> denied { write } for pid=226 comm="recovery" name="keystore"
> dev="mmcblk0p42" ino=726245 scontext=u:r:recovery:s0
> tcontext=u:object_r:keystore_data_file:s0 tclass=dir
> <5>[ 6.253540 / 01-01 09:17:40.910] type=1400 audit(33460.910:4): avc:
> denied { remove_name } for pid=226 comm="recovery" name="user_0"
> dev="mmcblk0p42" ino=726272 scontext=u:r:recovery:s0
> tcontext=u:object_r:keystore_data_file:s0 tclass=dir
> <5>[ 6.253564 / 01-01 09:17:40.910] type=1400 audit(33460.910:5): avc:
> denied { rmdir } for pid=226 comm="recovery" name="user_0"
> dev="mmcblk0p42" ino=726272 scontext=u:r:recovery:s0
> tcontext=u:object_r:keystore_data_file:s0 tclass=dir
> <5>[ 6.253658 / 01-01 09:17:40.910] type=1400 audit(33460.910:6): avc:
> denied { unlink } for pid=226 comm="recovery" name=".metadata"
> dev="mmcblk0p42" ino=726273 scontext=u:r:recovery:s0
> tcontext=u:object_r:keystore_data_file:s0 tclass=file
> When I fixed this error, but it is neverallow. so I can't fixed this issue.
> It cause build error because of neverallow.
>
> (google aosp policy path) android/external/sepolicy/keystore.te :
>
> 21 neverallow { domain -keystore } keystore_data_file:dir ~{ open create
> read getattr setattr search relabelto };
> 22 neverallow { domain -keystore } keystore_data_file:notdevfile_class_set
> ~{ relabelto getattr };
>
> It means all domain except keystore doesn't aceess at
> keystore_data_file:dir write, remove_name, rmdir ...and so one, and
> also all domain except keystore doesn't acess at keystore_data_file:file
> unlink.. right?
>
> but I could find next line.
> 24 neverallow { domain -keystore -init -kernel -recovery }
> keystore_data_file:dir *;
> 25 neverallow { domain -keystore -init -kernel -recovery }
> keystore_data_file:notdevfile_class_set *;
>
> It means recovery domain allows all oprations at keystore_data_file:dir ,
> and file.
>
> I had confuse this neverallow policy.
>
> Please help me...as soon as possible.
Nick's reply gets to the heart of the matter, but I just wanted to
clarify your misunderstanding of neverallow rules above. Each
neverallow rule is an assertion that is checked against all allow rules
in the policy. The latter two neverallows do not override or take
precedence over the first two - they must all pass in order for the
policy to build (and in order to pass the corresponding CTS test).
Also, neverallow rules are not "deny" rules (SELinux has no such
construct; it is strictly a whitelist not a blacklist); neverallow rules
do not implicitly allow their complement. Only what is explicitly
allowed by allow rules is permitted. The neverallow rules are only used
to check the policy, not to allow anything.
In this case, there are only two domains allowed by policy to access
keystore_data_file at all - init and keystore. init is only allowed
sufficient permissions to support creation of /data/misc/keystore and
restorecon_recursive /data, as performed by init.rc. So the first two
neverallow rules ensure that no domain other than keystore, even
including init, is allowed any permissions beyond the set required by
init to perform those actions. This ensures that no one later adds
further permissions even to init beyond this set. The latter two
neverallows ensure that no domain other than keystore, init, kernel, or
recovery are given any permissions at all to keystore_data_file. This
ensures that no one adds access for any domains other than those four.
All four neverallows must hold true for every allow rule in policy. In
current policy, since neither recovery nor kernel are allowed any access
to keystore_data_file, we can actually get rid of those exceptions
altogether:
https://android-review.googlesource.com/#/c/111740/
Those were likely just a legacy of old policy before access to
keystore_data_file was fully removed from all domains other than init
and keystore. Regardless, as Nick observed, it makes no sense for
recovery to have such access regardless of what policy may say.
Note that the neverallow rules are also checked by CTS so you can't just
modify them locally and expect to pass CTS, if that matters to you.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
