subpolicy switchable inside of programs (2008-11-13 21:40 by 匿名 #39872)
apparmor has one very cool feature that allows to define subpolices (called HATs) for particular program, let say /usr/bin/whatever. The program with API can switch between these subpolices and return back to "main" policy.
This allows for example apache to have "main" policy that has access to almost nothing and per virtual host subpolicies "virtual1" that gives access to /home/www/virtual1, "virtual2" that gives access to /home/www/virtual2. Now apache when serving virtual1 switches to "virtual1" subpolicy, when finishes it goes back to "main", then when serving virtual2 it switches to "virtual2" subpolicy.
This is very nice feature. SELinux for example cannot do anything like that.
How this looks in Tomoyo? Could such feature be implemented (if it's not already)
RE: subpolicy switchable inside of programs (2008-11-15 15:30 by kumaneko #39899)
Hello.
> apparmor has one very cool feature that allows to define subpolices
> (called HATs) for particular program, let say /usr/bin/whatever.
> The program with API can switch between these subpolices and return back to
> "main" policy.
>
> This allows for example apache to have "main" policy that has access to
> almost nothing and per virtual host subpolicies "virtual1" that gives access
> to /home/www/virtual1, "virtual2" that gives access to /home/www/virtual2.
> Now apache when serving virtual1 switches to "virtual1" subpolicy,
> when finishes it goes back to "main", then when serving virtual2 it switches
> to "virtual2" subpolicy.
>
Yes. That's a practical and useful feature. The key point of AppArmor's way is
random values called "magic" which are used for chhat() function.
> This is very nice feature. SELinux for example cannot do anything like that.
>
Right. This is because SELinux thinks that dropped privileges should not be
revived by userland. Returning to "main" policy by userland's operation is
a kind of privilege escalation which an attacker can use.
> How this looks in Tomoyo? Could such feature be implemented (if it's not
> already)
Regarding TOMOYO, so far there is no API for userland application.
There are several reasons.
One is that TOMOYO doesn't require modification of userland programs.
It is not a good thing to proliferate implementation specific APIs.
Forcing application program developers to support SELinux's API and AppArmor's
API and TOMOYO's API and more will burden the application developers. The worst
result is, application developers stop supporting none of these APIs.
Another one is that TOMOYO doesn't have hooks for fork() and exit() operations.
This means that TOMOYO can't allocate and free memory for per process storage
for storing "magic" value of chhat() function.
LSM has been providing hooks (security_task_alloc() and security_task_free())
for such purpose, but these hooks will be removed shortly by merging
"Copy on write credentials" patchset. I'm not sure AppArmor and TOMOYO can
revive these hooks.
By the way, TOMOYO 1.6.x supports process's state values which are controlled
by task.state[0] task.state[1] task.state[2] variables.
This feature can provide chhat() like functionality, but lacks "magic" values.
For example,
<kernel> /usr/sbin/sshd /bin/bash
allow_execute /bin/cat if task.uid=0 ; set task.state[0]=0
allow_execute /bin/cat if task.uid!=0 ; set task.state[0]=1
<kernel> /usr/sbin/sshd /bin/bash /bin/cat
allow_read /tmp/file1 if task.state[0]=0
allow_read /tmp/file2 if task.state[0]!=0
will allow root to read /tmp/file1 and non-root to read /tmp/file2 .
If you have a chance to insert some secret calls (which corresponds with
chhat()) within a process, you can use thse variables within a process.