Bug 456841 - SELinux is preventing hal-acl-tool (hald_acl_t) "write" to ./hald (var_run_t).
SELinux is preventing hal-acl-tool (hald_acl_t) "write" to ./hald (var_run_t).
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
9
x86_64 Linux
low Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-07-27 21:31 EDT by Charlie Brady
Modified: 2008-08-01 11:02 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-08-01 11:02:00 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Charlie Brady 2008-07-27 21:31:49 EDT
Summary:

SELinux is preventing hal-acl-tool (hald_acl_t) "write" to ./hald (var_run_t).

Detailed Description:

[SELinux is in permissive mode, the operation would have been denied but was
permitted due to permissive mode.]

SELinux is preventing hal-acl-tool (hald_acl_t) "write" to ./hald (var_run_t).
The SELinux type var_run_t, is a generic type for all files in the directory and
very few processes (SELinux Domains) are allowed to write to this SELinux type.
This type of denial usual indicates a mislabeled file. By default a file created
in a directory has the gets the context of the parent directory, but SELinux
policy has rules about the creation of directories, that say if a process
running in one SELinux Domain (D1) creates a file in a directory with a
particular SELinux File Context (F1) the file gets a different File Context
(F2). The policy usually allows the SELinux Domain (D1) the ability to write,
unlink, and append on (F2). But if for some reason a file (./hald) was created
with the wrong context, this domain will be denied. The usual solution to this
problem is to reset the file context on the target file, restorecon -v './hald'.
If the file context does not change from var_run_t, then this is probably a bug
in policy. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against the selinux-policy
package. If it does change, you can try your application again to see if it
works. The file context could have been mislabeled by editing the file or moving
the file from a different directory, if the file keeps getting mislabeled, check
the init scripts to see if they are doing something to mislabel the file.

Allowing Access:

You can attempt to fix file context by executing restorecon -v './hald'

Fix Command:

restorecon './hald'

Additional Information:

Source Context                system_u:system_r:hald_acl_t:s0
Target Context                system_u:object_r:var_run_t:s0
Target Objects                ./hald [ dir ]
Source                        hal-acl-tool
Source Path                   /usr/libexec/hal-acl-tool
Port                          <Unknown>
Host                          localhost.localdomain
Source RPM Packages           hal-0.5.11-2.fc9
Target RPM Packages           
Policy RPM                    selinux-policy-3.3.1-69.fc9
Selinux Enabled               True
Policy Type                   targeted
MLS Enabled                   True
Enforcing Mode                Permissive
Plugin Name                   mislabeled_file
Host Name                     localhost.localdomain
Platform                      Linux localhost.localdomain 2.6.25.6-55.fc9.x86_64
                              #1 SMP Tue Jun 10 16:05:21 EDT 2008 x86_64 x86_64
Alert Count                   164
First Seen                    Sat Apr 26 20:36:03 2008
Last Seen                     Sun Jul 27 21:23:52 2008
Local ID                      f51ed570-8d23-445b-81df-88c4bb4d0ad3
Line Numbers                  

Raw Audit Messages            

host=localhost.localdomain type=AVC msg=audit(1217208232.44:873): avc:  denied 
{ write } for  pid=12449 comm="hal-acl-tool" name="hald" dev=dm-0 ino=3493107
scontext=system_u:system_r:hald_acl_t:s0 tcontext=system_u:object_r:var_run_t:s0
tclass=dir

host=localhost.localdomain type=AVC msg=audit(1217208232.44:873): avc:  denied 
{ add_name } for  pid=12449 comm="hal-acl-tool" name="acl-list.DS2ZEU"
scontext=system_u:system_r:hald_acl_t:s0 tcontext=system_u:object_r:var_run_t:s0
tclass=dir

host=localhost.localdomain type=AVC msg=audit(1217208232.44:873): avc:  denied 
{ create } for  pid=12449 comm="hal-acl-tool" name="acl-list.DS2ZEU"
scontext=system_u:system_r:hald_acl_t:s0 tcontext=system_u:object_r:var_run_t:s0
tclass=file

host=localhost.localdomain type=SYSCALL msg=audit(1217208232.44:873):
arch=c000003e syscall=2 success=yes exit=4 a0=1601aa0 a1=c2 a2=1b6
a3=8101010101010100 items=0 ppid=2634 pid=12449 auid=4294967295 uid=0 gid=0
euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295
comm="hal-acl-tool" exe="/usr/libexec/hal-acl-tool"
subj=system_u:system_r:hald_acl_t:s0 key=(null)
Comment 1 Charlie Brady 2008-07-27 21:32:33 EDT
[charlieb@localhost blue]$ sudo ls -d --lcontext /var/run/hald
[sudo] password for charlieb: 
drwx------ 2 system_u:object_r:var_run_t:s0   haldaemon haldaemon 4096
2008-07-27 21:23 /var/run/hald
[charlieb@localhost blue]$ sudo /sbin/restorecon /var/run/hald
[charlieb@localhost blue]$ sudo ls -d --lcontext /var/run/hald
drwx------ 2 system_u:object_r:var_run_t:s0   haldaemon haldaemon 4096
2008-07-27 21:23 /var/run/hald
[charlieb@localhost blue]$ 
Comment 2 Daniel Walsh 2008-07-28 16:22:56 EDT
Something strange is going on here.

ls -d --lcontext /var/run/hald
drwx------ 2 system_u:object_r:hald_var_run_t:s0 haldaemon haldaemon 4096
2008-07-18 14:14 /var/run/hald

matchpathcon /var/run/hald
/var/run/hald   system_u:object_r:hald_var_run_t:s0

Is hald a symbolic link?  Or something in the path?

Comment 3 Charlie Brady 2008-07-28 16:50:30 EDT
(In reply to comment #2)

> Is hald a symbolic link?  Or something in the path?

I don't know. I'm told ./hald, but not cwd at the time, so we can only guess,
right? I think there's a deficiency in the audit logs.



Comment 4 Charlie Brady 2008-07-28 17:07:44 EDT
My guess is that these:

> Raw Audit Messages            
> 
> host=localhost.localdomain type=AVC msg=audit(1217208232.44:873): avc:  denied 
> { write } for  pid=12449 comm="hal-acl-tool" name="hald" dev=dm-0 ino=3493107
> scontext=system_u:system_r:hald_acl_t:s0 tcontext=system_u:object_r:var_run_t:s0
> tclass=dir
> 
> host=localhost.localdomain type=AVC msg=audit(1217208232.44:873): avc:  denied 
> { add_name } for  pid=12449 comm="hal-acl-tool" name="acl-list.DS2ZEU"
> scontext=system_u:system_r:hald_acl_t:s0 tcontext=system_u:object_r:var_run_t:s0
> tclass=dir
> 
> host=localhost.localdomain type=AVC msg=audit(1217208232.44:873): avc:  denied 
> { create } for  pid=12449 comm="hal-acl-tool" name="acl-list.DS2ZEU"
> scontext=system_u:system_r:hald_acl_t:s0 tcontext=system_u:object_r:var_run_t:s0
> tclass=file

are all from:

        /* success; now atomically set the new list */
        g_file_set_contents (PACKAGE_LOCALSTATEDIR "/run/hald/acl-list",
                             new_acl_file_contents,
                             strlen (new_acl_file_contents),
                             NULL);

from the hal-acl-tool source code.

http://library.gnome.org/devel/glib/unstable/glib-File-Utilities.html#g-file-set-contents

g_file_set_contents ()

gboolean            g_file_set_contents                 (const gchar *filename,
                                                         const gchar *contents,
                                                         gssize length,
                                                         GError **error);

Writes all of contents to a file named filename, with good error checking. If a
file called filename already exists it will be overwritten.

This write is atomic in the sense that it is first written to a temporary file
which is then renamed to the final name. Notes:

    * On Unix, if filename already exists hard links to filename will break.
Also since the file is recreated, existing permissions, access control lists,
metadata etc. may be lost. If filename is a symbolic link, the link itself will
be replaced, not the linked file.
    * On Windows renaming a file will not remove an existing file with the new
name, so on Windows there is a race condition between the existing file being
removed and the temporary file being renamed.
    * On Windows there is no way to remove a file that is open to some process,
or mapped into memory. Thus, this function will fail if filename already exists
and is open.

If the call was sucessful, it returns TRUE. If the call was not successful, it
returns FALSE and sets error. The error domain is G_FILE_ERROR. Possible error
codes are those in the GFileError enumeration.

filename : 	name of a file to write contents
Comment 5 Daniel Walsh 2008-07-29 15:37:25 EDT
We seem to be having lots of labeling problem on your system.  I now believe
something went wrong when you installed selinux policy.  Can you grab the latest
RPMs and try to reinstall them with a --force qualifier.

Then run restorecon -R -v /var/run
Comment 6 Charlie Brady 2008-07-29 16:40:50 EDT
(In reply to comment #5)
> We seem to be having lots of labeling problem on your system.  I now believe
> something went wrong when you installed selinux policy.  Can you grab the latest
> RPMs and try to reinstall them with a --force qualifier.

OK. Surprisingly, I don't have the latest in my yum cache.

[charlieb@localhost ~]$ sudo find /var/cache/yum/ -name selinux\*
[sudo] password for charlieb: 
/var/cache/yum/updates/packages/selinux-policy-targeted-3.3.1-78.fc9.noarch.rpm
/var/cache/yum/updates/packages/selinux-policy-3.3.1-72.fc9.noarch.rpm
/var/cache/yum/updates/packages/selinux-policy-devel-3.3.1-72.fc9.noarch.rpm
/var/cache/yum/updates/packages/selinux-policy-devel-3.3.1-78.fc9.noarch.rpm
/var/cache/yum/updates/packages/selinux-policy-targeted-3.3.1-72.fc9.noarch.rpm
/var/cache/yum/updates/packages/selinux-policy-3.3.1-78.fc9.noarch.rpm
[charlieb@localhost ~]$ 
[charlieb@localhost ~]$ rpm -q selinux-policy selinux-policy-targeted
selinux-policy-3.3.1-79.fc9.noarch
selinux-policy-targeted-3.3.1-79.fc9.noarch
[charlieb@localhost ~]$ 

Well, rpm doesn't see anything wrong about what's installed:

[charlieb@localhost ~]$ sudo rpm -V selinux-policy selinux-policy-targeted
[charlieb@localhost ~]$ sudo rpm -q selinux-policy selinux-policy-targeted
selinux-policy-3.3.1-79.fc9.noarch
selinux-policy-targeted-3.3.1-79.fc9.noarch
[charlieb@localhost ~]$ 

But I'll try to force install anyway:

[charlieb@localhost ~]$ sudo rpm -Uhv --force selinux-policy-*rpm
Preparing...                ########################################### [100%]
   1:selinux-policy         ########################################### [ 50%]
   2:selinux-policy-targeted########################################### [100%]
libsemanage.validate_handler: selinux user unconfined_u does not exist
libsemanage.validate_handler: seuser mapping [__default__ -> (unconfined_u, s0)]
is invalid
libsemanage.dbase_llist_iterate: could not iterate over records
semodule:  Failed!
[charlieb@localhost ~]$ 

> Then run restorecon -R -v /var/run

I guess I'll leave that until later.
Comment 7 Charlie Brady 2008-07-29 17:02:35 EDT
[charlieb@localhost ~]$ sudo /usr/sbin/sestatus 
[sudo] password for charlieb: 
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 22
Policy from config file:        targeted
[charlieb@localhost ~]$ sudo /usr/sbin/semanage user -l 

                Labeling   MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range                      SELinux Roles


Looks to me that this thread is a similar issue:

http://www.engardelinux.org/modules/index/list_archives.cgi?list=fedora-selinux&page=0054.html&month=2008-07
Comment 8 Daniel Walsh 2008-08-01 11:02:00 EDT
I believe we resolved this issue by reinstalling selinux policy and relableing.

Note You need to log in before you can comment on or make changes to this bug.