After the most recent update to the strict policy (selinux-policy-strict-1.13.7-1), Mozilla web browser will not start in enforcing mode. It does *not* produce *any* avc denied messages in enforcing mode. Below are the avc denied messages that are produced when it does start in permissive mode:
Jun 20 20:31:30 new2 kernel: audit(1087777890.697:0): avc: denied { write } for pid=3471 exe=/usr/lib/mozilla-1.6/mozilla-xremote-client name=X0 dev=hda2 ino=1840568 scontext=richard:staff_r:staff_mozilla_t tcontext=system_u:object_r:xdm_tmp_t tclass=sock_file Jun 20 20:31:34 new2 kernel: audit(1087777894.263:0): avc: denied { unlink } for pid=3457 exe=/usr/lib/mozilla-1.6/mozilla-bin name=.fonts.cache-1 dev=hda2 ino=1091707 scontext=richard:staff_r:staff_mozilla_t tcontext=richard:object_r:staff_home_t tclass=file
Here is part of the output from fixfiles relabel prior to testing this problem :
/usr/sbin/setfiles: read 1499 specifications /usr/sbin/setfiles: labeling files under / /usr/sbin/setfiles: relabeling /home/richard/.fonts.cache-1 from richard:object_r:staff_mozilla_rw_t to richard:object_r:staff_home_t /usr/sbin/setfiles: relabeling /.autofsck from system_u:object_r:root_t to system_u:object_r:default_t /usr/sbin/setfiles: hash table stats: 374956 elements, 62564/65536 buckets used, longest chain length 15
HTH Richard Hally
On Mon, 21 Jun 2004 10:47, Richard Hally rhallyx@mindspring.com wrote:
Jun 20 20:31:30 new2 kernel: audit(1087777890.697:0): avc: denied { write } for pid=3471 exe=/usr/lib/mozilla-1.6/mozilla-xremote-client name=X0 dev=hda2 ino=1840568 scontext=richard:staff_r:staff_mozilla_t tcontext=system_u:object_r:xdm_tmp_t tclass=sock_file
That's a known issue. The policy regarding X client applications connecting to servers needs to be re-written to make it cleaner. For the moment just allow this.
Jun 20 20:31:34 new2 kernel: audit(1087777894.263:0): avc: denied { unlink } for pid=3457 exe=/usr/lib/mozilla-1.6/mozilla-bin name=.fonts.cache-1 dev=hda2 ino=1091707 scontext=richard:staff_r:staff_mozilla_t tcontext=richard:object_r:staff_home_t tclass=file
This is an instance of the big problem with having multiple domains used for applications run from the user's account. They have files that are used by multiple applications and there is no consistent way of managing them. The .fonts.cache file is used by many programs other than mozilla, most of which run as staff_t (in the case of staff_r logins) and therefore the type is staff_home_t. Labelling the file as staff_mozilla_rw_t is not going to work as I think that some programs will unlink and recreate it.
Russell Coker wrote:
On Mon, 21 Jun 2004 10:47, Richard Hally rhallyx@mindspring.com wrote:
Jun 20 20:31:30 new2 kernel: audit(1087777890.697:0): avc: denied { write } for pid=3471 exe=/usr/lib/mozilla-1.6/mozilla-xremote-client name=X0 dev=hda2 ino=1840568 scontext=richard:staff_r:staff_mozilla_t tcontext=system_u:object_r:xdm_tmp_t tclass=sock_file
That's a known issue. The policy regarding X client applications connecting to servers needs to be re-written to make it cleaner. For the moment just allow this.
<snip>
Do you know what changed from the previous policy to cause this avc denied message or what else may have changed to cause Mozilla to no longer start? What change may have caused the execution of mozilla-xremote-client? My version of Mozilla is the same on both of my test systems and the one with the previous (1.13.4-6) policy doesn't have this problem. And I can't find any the difference that is causing this??
Richard Hally
On Mon, Jun 21, 2004 at 02:01:37PM +1000, Russell Coker wrote:
is staff_home_t. Labelling the file as staff_mozilla_rw_t is not going to work as I think that some programs will unlink and recreate it.
Has any thought been given to automatically, through policy, applying certain labels to files as they are created?
On Wed, 23 Jun 2004 08:01, "Charles R. Anderson" cra@WPI.EDU wrote:
On Mon, Jun 21, 2004 at 02:01:37PM +1000, Russell Coker wrote:
is staff_home_t. Labelling the file as staff_mozilla_rw_t is not going to work as I think that some programs will unlink and recreate it.
Has any thought been given to automatically, through policy, applying certain labels to files as they are created?
Yes that is done. If mozilla creates the file in question and nothing else unlinks it then things will be fine. However if something else creates it first or unlinks it and re-creates it then it gets a type that Mozilla may not be permitted write or read/write access (depending on policy).
On Wed, Jun 23, 2004 at 01:07:59PM +1000, Russell Coker wrote:
Has any thought been given to automatically, through policy, applying certain labels to files as they are created?
Yes that is done. If mozilla creates the file in question and nothing else unlinks it then things will be fine. However if something else creates it first or unlinks it and re-creates it then it gets a type that Mozilla may not be permitted write or read/write access (depending on policy).
I realize that file creation inherits the parent process's context. What I was suggesting was something to override that based on filesystem path pattern, parent directory context, or something like that.
On Wed, 2004-06-23 at 09:06, Charles R. Anderson wrote:
I realize that file creation inherits the parent process's context. What I was suggesting was something to override that based on filesystem path pattern, parent directory context, or something like that.
New files default to the security type of the parent directory, unless the policy includes a file_type_auto_trans() macro (or type_transition rule) that specifies a different type based on the creating process domain, parent directory type, and file class.
selinux@lists.fedoraproject.org