[apparmor] Working principle of alias rules

[Seth Arnold]

On Wed, Jul 18, 2018 at 02:14:08PM -0000, rockit at openmailbox.org wrote:
> I have some questions for apparmor alias rules. Is it correct that an
> alias rule won't directly have an influence on which files can be
> accessed  on a certain rewritten path, i.e. the actual profile for the
> program is what matters more?

If I've understood the question correctly, you have to consider both a
profile and whatever alias rules the profile may load when determining
what resources the profiles allows processes to access.

> Could you make a program less confined
> just by alias rules? Sure you add another path, but on this path you are
> still allowed to only access files as described in the original profile
> of the program. Is this correct?

There's two ways of looking at this:
- "yes", even when "alias" rules are used, the profile is still confining
  any processes running within the profile, and all their access control
  decisions are made by consulting the profile.
- "no", the "alias" rules *are* a loosening of privileges, since one path
  given in the profile can grant access to more files.

I think you've got the correct understanding.

> What is the reason a rewrite path for
> "/" -> "/rw/" does not apply to all the rules, i.e. you have to
> specifically rewrite other paths too, like "/var/" -> "/rw/var/" ?

Are you sure about this? I couldn't find anything in the code that would
forbid / -> /rw from working, and a simple test (using / -> /AAAA instead,
so that it would stand out clearly in the dumps) seems to show it working
as I expect:

sarnold at hunt:~$ echo "alias / -> /AAAA, profile p { / r,}" | apparmor_parser -Q --dump=dfa-states
Warning from stdin (line 1): apparmor_parser: cannot use or update cache, disable, or force-complain via stdin
{1} <== (allow/deny/audit/quiet)
{2} (0x 10004/0/0/0)
{6} (0x 10004/0/0/0)

{1} -> {2}: 0x2f /
{2}  (0x 10004/0/0/0) -> {3}: 0x41 A
{3} -> {4}: 0x41 A
{4} -> {5}: 0x41 A
{5} -> {6}: 0x41 A

{1} <== (allow/deny/audit/quiet)
{2} (0x 4/0/0/0)

{1} -> {2}: 0x2
{1} -> {2}: 0x4
{1} -> {2}: 0x7
{1} -> {2}: 0x9
{1} -> {2}: 0xa
{1} -> {2}: 0x20 \
{1} -> {3}: 0x34 4
{3} -> {4}: 0x0
{4} -> {2}: 0x31 1

Note that the compiled policy looks the same as what I would expect it to
expand to:

sarnold at hunt:~$ echo "profile p { /AAAA r, / r,}" | apparmor_parser -Q --dump=dfa-states
Warning from stdin (line 1): apparmor_parser: cannot use or update cache, disable, or force-complain via stdin
{1} <== (allow/deny/audit/quiet)
{2} (0x 10004/0/0/0)
{6} (0x 10004/0/0/0)

{1} -> {2}: 0x2f /
{2}  (0x 10004/0/0/0) -> {3}: 0x41 A
{3} -> {4}: 0x41 A
{4} -> {5}: 0x41 A
{5} -> {6}: 0x41 A

{1} <== (allow/deny/audit/quiet)
{2} (0x 4/0/0/0)

{1} -> {2}: 0x2
{1} -> {2}: 0x4
{1} -> {2}: 0x7
{1} -> {2}: 0x9
{1} -> {2}: 0xa
{1} -> {2}: 0x20 \
{1} -> {3}: 0x34 4
{3} -> {4}: 0x0
{4} -> {2}: 0x31 1


If you have found a counter example, please share. :)

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20180718/9afc951b/attachment.sig>