-----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----- _______________________________________________ Gamin-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gamin-list
