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-hardened@g.o mailing list |