1 |
RSBAC permits network access control. Maybe you could do what you are |
2 |
looking for with the RC model |
3 |
|
4 |
2008/11/25 <schism@×××××××××.org>: |
5 |
> On Tue, Nov 25, 2008 at 05:13:03PM +0200, Jan Klod wrote: |
6 |
>> Is there some known good way to make an effective whitelist of applications, |
7 |
>> which are granted network access? |
8 |
> |
9 |
> More or less; both grsecurity's RBAC and SElinux support this, but on a per-user |
10 |
> basis, not per-application. Novell's AppArmor does things by path (application) |
11 |
> instead of user. You may also specify CONFIG_GRKERNSEC_SOCKET in your kernel |
12 |
> configuration for less granular control (deny server or client sockets by GID). |
13 |
> You may also somewhat approximate that with the 'owner' module in iptables, but |
14 |
> administration quickly becomes cumbersome. |
15 |
> |
16 |
>> By the way, there is another related question: I remember, I once started |
17 |
>> googleearth as user1 and had firefox running as user2; really, googleearth |
18 |
>> opened link into user2's firefox! So I can easily have an illusion of |
19 |
>> protection such a way (user1 application bypasses firewall by signalling |
20 |
>> user2 application somehow). |
21 |
> |
22 |
> You likely had both users running under the same X display and were using one |
23 |
> of the more user-friendly window managers. Add Xauth into the mix, and your |
24 |
> result doesn't surprise me. |
25 |
> |
26 |
>> What the question really is? How can I know, that particular application can |
27 |
>> make / accept a dangerous signal (or other interprocess comm.) and how can I |
28 |
>> forbid that, if necessary? |
29 |
> |
30 |
> More than likely, the issue you perceive is not with the underlying access |
31 |
> control mechanisms, but with the way some system configurations bypass those |
32 |
> controls to make things more user-friendly. GUI apps in particular have dozens |
33 |
> of ways to communicate with each other, depending on the windowing environment, |
34 |
> and you'll drive yourself insane trying to prevent all but the "good" ones. If |
35 |
> two applications absolutely cannot be allowed to communicate, run them in |
36 |
> separate machines. |
37 |
> |
38 |
> --dc |
39 |
> |
40 |
> |