Re: [gamin] gam_server and SElinux

[Daniel J Walsh <dwalsh redhat com>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Daniel Veillard wrote:
> On Mon, May 12, 2008 at 02:04:56PM +0100, Jonathan Underwood wrote:
>> Dear Daniel,
>>
>> Any chance you could cast your eye over:
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=437633
>>
>> 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...
> 
> Daniel
> 
Well most !root UID's run with the same context so it would not be a lot
of gam_servers running.  The problem from an SELinux point of view is,
when rpm installs are run via packagekitd they run as rpm_t which is a
very unconfined domain,  later if a confined domain can talk to gamin it
can circumvent security.  So I guess the question would be, what does
the library do when it is gamin_server connect call is denied?  How does
the gamin_library find the gamin_server that is running with the correct
UID?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkgoefQACgkQrlYvE4MpobOlGQCg63sLO3uRkllrI0kywdr8m/x4
IdQAoLSethmOiKo+U0f0hhSdvn9ZTvrN
=xngS
-----END PGP SIGNATURE-----