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