Re: [gamin] gam_server and SElinux
- From: Daniel Veillard <veillard redhat com>
- To: Jonathan Underwood <jonathan underwood gmail com>, Daniel J Walsh <dwalsh redhat com>
- Cc: gamin-list gnome org
- Subject: Re: [gamin] gam_server and SElinux
- Date: Mon, 12 May 2008 11:56:06 -0400
On Mon, May 12, 2008 at 02:04:56PM +0100, Jonathan Underwood wrote:
> Dear Daniel,
> Any chance you could cast your eye over:
> In brief, there's a bad interaction between gam_server and selinux
> which is breaking fail2ban. The issue is, if some process starts a
> gam_server as UID root it will be assigned a SElinux domain according
> to the process that started gam_server. If another UID root process
> tries to connect to the socket of that first gam_server, according to
> the gamin logic it should be allowed, since the UID is correct.
yes that's the logic, based on the needs for the desktop
that was put into gamin design.
> However, the second process fails to connect because it has a
> different SElinux domain. In other words, can gam_server be made
> SElinux aware? Your thoughts would be much appreciated!
Honnestly, gamin is in very low priority maintainance mode ATM,
and i have no experience of what it takes to 'make gam_server SElinux
aware'. It was really designed so that each user gets a different
server, and when different programs runs for the same user they share
the access. The fact that gam_server got started because application A
or application B on the desktop needed the monitoring feature should
not matter, they really should share the instance.
We really do not want to see a gam_server for nautilus, one for
firefox, etc... The server is dynamically started by the first app
needing FAM, the others connect based on the user ID being shared.
the whole security design of gamin is based on the assumption that all
process running for a given UID share their filesystem permissions
and hence can share the gam_server instances. As a result the server
runs under the ID of the given user.
SELinux adds an extra set of arbitrary boundaries, this wasn't
expected at gamin design time. i don't know how that could work
with the current principles of FAM/gamin use for all the desktop
and systems applications.
I would really prefer if that could be fixed at the policy level,
if not, it probably mean way more than just popping new gam_servers
around each time there is a failure. Gamin is horribly hard to debug
already, stuck between broken kernel APIs and a broken FAM library
API, I wish a lot of luck to anybody who would like to take over, fix
it or rewrite it...
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
] [Thread Prev