Re: [gentoo-hardened] whitelist of apps granted network access?

[Javier Martínez]

RSBAC permits network access control. Maybe you could do what you are
looking for with the RC model

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