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 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
and Sep 23 20:26:51 fedora kernel: audit(1095996411.010:0): avc: denied { write } for pid=4838 path=/lib/ld-2.3.3.so dev=hda2 ino=3178536 scontext=user_u:user_r:user_t tcontext=system_u:object_r:ld_so_t tclass=file
Running in permissive mode both start, and /lib/ld-2.3.3.so is not written to.
Write to /lib/ld-2.3.3.so ????? Did I do something stupid?
tom
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.
When in strict/enforcing, mozilla fails to start because or the /lib/ld-2.3.3.so 'violation'.
I get the .fonts.cache avc when running in permissive mode. I haven't modified the policy to allow the /lib/ld-2.3.3.so access to see the effect of this failing.
Regarding the /lib/ld-2.3.3.so avc, I'm noticing this when I try to start firefox, thunderbird and gaim, but nothing else.. Could it also be a gtk2 problem?
tom
On Fri, 24 Sep 2004 00:18:05 -0400, Colin Walters walters@redhat.com wrote:
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.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
Still get /lib/ld-2.3.3.so avc with latest rawhide gtk2 download.
I'm not sure its the right place, but I'll bugzilla this agains glibc.
tom
On Fri, 24 Sep 2004 07:26:14 -0700, Tom London selinux@gmail.com wrote:
When in strict/enforcing, mozilla fails to start because or the /lib/ld-2.3.3.so 'violation'.
I get the .fonts.cache avc when running in permissive mode. I haven't modified the policy to allow the /lib/ld-2.3.3.so access to see the effect of this failing.
Regarding the /lib/ld-2.3.3.so avc, I'm noticing this when I try to start firefox, thunderbird and gaim, but nothing else.. Could it also be a gtk2 problem?
tom
On Fri, 24 Sep 2004 00:18:05 -0400, Colin Walters walters@redhat.com wrote:
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.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
-- Tom London
This is curious....
I've straced gaim both under strict/enforcing and strict/permissive. It appears that under strict/enforcing, a call to 'mprotect(..., ..., PROT_READ|PROT_WRITE)' fails, and gaim segv faults. This same call succeeds under strict/permissive, and gaim then starts successfully.
This also seems to be where the AVC to /lib/ld-2.3.3.so is produced.
Here is the bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=133505
tom
On Fri, 24 Sep 2004 08:21:22 -0700, Tom London selinux@gmail.com wrote:
Still get /lib/ld-2.3.3.so avc with latest rawhide gtk2 download.
I'm not sure its the right place, but I'll bugzilla this agains glibc.
tom
On Fri, 24 Sep 2004 07:26:14 -0700, Tom London selinux@gmail.com wrote:
When in strict/enforcing, mozilla fails to start because or the /lib/ld-2.3.3.so 'violation'.
I get the .fonts.cache avc when running in permissive mode. I haven't modified the policy to allow the /lib/ld-2.3.3.so access to see the effect of this failing.
Regarding the /lib/ld-2.3.3.so avc, I'm noticing this when I try to start firefox, thunderbird and gaim, but nothing else.. Could it also be a gtk2 problem?
tom
On Fri, 24 Sep 2004 00:18:05 -0400, Colin Walters walters@redhat.com wrote:
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.
-- fedora-selinux-list mailing list fedora-selinux-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-selinux-list
-- Tom London
-- Tom London
selinux@lists.fedoraproject.org