Re: [PATCH v10 5/5] overlayfs: override_creds=off option bypass creator_cred

[Mark Salyzyn <salyzyn@android.com>]

[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]

On 7/25/19 9:12 AM, Amir Goldstein wrote:
> [reduce CC list]
>
>>> I am fine with this patch, but would like to request that you add @sb arg
>>> to the ovl_revert_creds() helper, so it is more useful for other things in the
>>> future that scope the underlying layers access (like shutdown).
>> Will respin and retest.
>>
> Apropos testing, I wanted to bring up this issue.
> I noticed that the test coverage I have for unprivileged user access to
> overlayfs is lacking.
>
> xfstests has several generic tests that use _runas and run on overlayfs,
> but that's only for pure upper files.
>
> unionmount-testsuite is always run as root, because it needs to
> mount/umount/etc.
> I am working on a new mode ./run --ov --runas=1
> to seteuid(1);setegid(1) before every test (after set_up and mount)
> That's fine for basic UNIX permission and capability checks, but does not cover
> more complex setups like with sepolicy.
>
> I was thinking maybe to execute "./run --ov --set-up" with mounter process
> credentials (e.g. initd) and then add a new mode "./run --ov --no-set-up"
> which uses the mount prepared by the mounter and runs the tests.
>
> I wanted to get feedback on the ideas above if they are useful for
> your use cases? Is that enough or is there more functionality required
> to cover more use cases?
>
> Thanks,
> Amir.

I had already filed an internal bug to find a solution for this because 
I did not have a full answer to this vacuum in testing. Everything I do 
is cumbersome, manual or instrumented w.r.t. overlayfs with a poor 
velocity because solution is checked on all android kernel releases; and 
relies on a functional device (can be run under emulator) to smoke test 
the integrated result (where we do have some automation).

These new problems that added extra patches to this series were only 
uncovered over the last two months of investigation and root cause on 
4.14 and (very recently) 4.19 devices and have not discovered any 
automation (well, two simple tests is not enough) that pleases me.

We have no problem running functionality or security tests on 
"userdebug" (near identical to "user" builds that go to the planet) that 
is in effect rooted (su root <command>) and may have a limited few extra 
test or engineering excecutables, with a policy to upload them to 
/data/nativetest/ otherwise. Our standard POSIX tools are delivered from 
toybox, so keep that in mind.

I had looked at https://github.com/SELinuxProject/selinux-testsuite, but 
it could not easily be Android'ified because of reliance for on-target 
for Bash, Perl and Python. But I am sure there are many tests scenarios 
there that could be 'translated'.

An Android'ified test that would test sepolicy would probably leverage 
our existing policy 
(https://android.git.corp.google.com/platform/system/sepolicy/+/HEAD/ 
<https://www.google.com/url?q=https://www.google.com/url?q%3Dhttps://android.git.corp.google.com/platform/system/core/%252B/HEAD/fs_mgr/README.overlayfs.md%2523%26sa%3DD%26ust%3D1564076098999000%26usg%3DAFQjCNGi5PJ_zn-Jm_Qykb3PfLbNfEgZwA&source=gmail&ust=1564158899354000&usg=AFQjCNHVYoSdS1JcqtSpiVENiNKx-w_2cQ>) 
and free rein in /data/local/tmp/ to play mounting games.

Sincerely -- Mark Salyzyn



[-- Attachment #2: Type: text/html, Size: 5866 bytes --]