| 1 |
Niels Provos wrote: |
| 2 |
> On 4/26/06, Joshua Brindle <method@g.o> wrote: |
| 3 |
> |
| 4 |
>> Well, systrace is path based so you can apply all those arguments |
| 5 |
>> directly. I don't understand what you mean by systrace is not MAC, what |
| 6 |
>> is it? It has a policy, it enforces access control. I guess choosing to |
| 7 |
>> |
| 8 |
> |
| 9 |
> Let's take this opportunity to avoid misunderstandings. I don't know |
| 10 |
> very much about mandatory access control nor SELinux in particular. |
| 11 |
> However, I certainly support the statement that Systrace is not a MAC |
| 12 |
> system nor does it want to be one. It would be great if you could |
| 13 |
> help improve my understanding of SELinux by explaining the SELinux |
| 14 |
> policy that governs, for example, your IRC client. |
| 15 |
> |
| 16 |
That is fair. If noone involved considers systrace MAC then I'm less |
| 17 |
inclined to care about its availability, I'm still very concerned about |
| 18 |
privilege escalation and user interaction. I will not concede that this |
| 19 |
sort of activity (particularly the privilege escalation) is very dangerous. |
| 20 |
|
| 21 |
SELinux is mandatory so the policy would already be loaded into the |
| 22 |
kernel. The irc client executable would be labeled (something like |
| 23 |
irc_exec_t). The user shell process would have a label (user_t) and |
| 24 |
user_t executing irc_exec_t would cause a transition into user_irc_t. |
| 25 |
The user_irc_t would then only have access to the resources it needs, |
| 26 |
network, its own files in your home and tmp. Derived domains like |
| 27 |
user_irc_t are used to seperate user apps from one another (without the |
| 28 |
assistance of DAC). |
| 29 |
|
| 30 |
There are tons of resources about how selinux works policy-wise though. |
| 31 |
What in particular do you want to know? |
| 32 |
-- |
| 33 |
gentoo-security@g.o mailing list |
Archives