On Thu, 2004-09-23 at 20:33 -0700, Tom London wrote:
> After being on the road for a bit, I did a 'yum update' to grab the new stuff.
>
> After doing so (>300 packages), running strict/enforcing,
> firefox and gaim fail to start:
>
> Sep 23 20:10:29 fedora kernel: audit(1095995429.976:0): avc: denied
> { write } for pid=4755 path=/lib/ld-2.3.3.so dev=hda2 ino=3178536
> scontext=user_u:user_r:user_mozilla_t
> tcontext=system_u:object_r:ld_so_t tclass=file
That is bizarre. My guess is some recent glibc change.
> Sep 23 20:10:31 fedora kernel: audit(1095995431.164:0): avc: denied
> { unlink } for pid=4755 exe=/usr/lib/firefox-0.10.0/firefox-bin
> name=.fonts.cache-1 dev=hda2 ino=2752979
> scontext=user_u:user_r:user_mozilla_t
> tcontext=user_u:object_r:user_home_t tclass=file
The fontconfig cache as it's currently implemented is going to be a
perennial problem for SELinux. Any application that uses fontconfig
will want to read and write to the cache file.
Currently the fontconfig library has a bit of code:
FcBool
FcGlobalCacheSave (FcGlobalCache *cache,
const FcChar8 *cache_file)
{
/* ... */
#if defined (HAVE_GETUID) && defined (HAVE_GETEUID)
/* Set-UID programs can't safely update the cache */
if (getuid () != geteuid ())
return FcFalse;
#endif
But there's really no equivalent to that check for SELinux.
A short term solution might be to give .fonts.cache-1 its own type by
patching fontconfig to put it in a ~/.fontconfig directory which has a
type user_font_cache_t that we can statically assign, and
when .fonts.cache-1 is created in that directory it should inherit the
type, so it won't just be user_home_t. Then for every user domain
except user_t we just dontaudit writes to it.
Was mozilla actually not starting because of this? That would probably
be a bug in the fontconfig libraries.
A longer term solution would be to make the fontconfig cache a daemon
that controls access to fonts more precisely.
Attachment:
signature.asc
Description: This is a digitally signed message part
