Bug 183906 - avc denied with hal and mountpoints
avc denied with hal and mountpoints
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: selinux-policy-targeted (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-03 11:02 EST by Orion Poplawski
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version: 2.2.42-2.fc5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-28 18:30:32 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 Orion Poplawski 2006-03-03 11:02:38 EST
Description of problem:

Fresh install of rawhide 20060302.   denied messages:

avc:  denied  { getattr } for  pid=1242 comm="fsck" name="mcelog" dev=tmpfs
ino=3104 scontext=system_u:system_r:fsadm_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1242 comm="fsck" name="hpet" dev=tmpfs
ino=3084 scontext=system_u:system_r:fsadm_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1242 comm="fsck" name="kmsg" dev=tmpfs
ino=2033 scontext=system_u:system_r:fsadm_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1242 comm="fsck" name="kcore" dev=proc
ino=4026531861 scontext=system_u:system_r:fsadm_t:s0
tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file
avc:  denied  { getattr } for  pid=1242 comm="fsck" name=".in_sysinit" dev=tmpfs
ino=1111 scontext=system_u:system_r:fsadm_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=file
avc:  denied  { getattr } for  pid=1242 comm="fsck" name="initctl" dev=tmpfs
ino=1066 scontext=system_u:system_r:fsadm_t:s0
tcontext=system_u:object_r:initctl_t:s0 tclass=fifo_file

avc:  denied  { getattr } for  pid=1259 comm="mount" name="sg0" dev=tmpfs
ino=3445 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:scsi_generic_device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="mcelog" dev=tmpfs
ino=3104 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="hpet" dev=tmpfs
ino=3084 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="random" dev=tmpfs
ino=2114 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:random_device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="urandom" dev=tmpfs
ino=2105 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:urandom_device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="kmsg" dev=tmpfs
ino=2033 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="ppp" dev=tmpfs
ino=1159 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:ppp_device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="parport3" dev=tmpfs
ino=1156 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:printer_device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="parport2" dev=tmpfs
ino=1155 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:printer_device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="parport1" dev=tmpfs
ino=1154 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:printer_device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="parport0" dev=tmpfs
ino=1153 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:printer_device_t:s0 tclass=chr_file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="kcore" dev=proc
ino=4026531861 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:proc_kcore_t:s0 tclass=file
avc:  denied  { getattr } for  pid=1259 comm="mount" name="initctl" dev=tmpfs
ino=1066 scontext=system_u:system_r:mount_t:s0
tcontext=system_u:object_r:initctl_t:s0 tclass=fifo_file

avc:  denied  { search } for  pid=2637 comm="hald" name="export" dev=dm-0
ino=30721 scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:user_home_t:s0 tclass=dir
avc:  denied  { name_connect } for  pid=2742 comm="hostname" dest=111
scontext=system_u:system_r:hostname_t:s0
tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
avc:  denied  { name_bind } for  pid=2742 comm="hostname" src=798
scontext=system_u:system_r:hostname_t:s0
tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket

avc:  denied  { write } for  pid=7263 comm="hostname" name="[65948]" dev=pipefs
ino=65948 scontext=root:system_r:hostname_t:s0
tcontext=root:system_r:unconfined_t:s0-s0:c0.c255 tclass=fifo_file
avc:  denied  { read } for  pid=7263 comm="hostname" name="sendmail.mc" dev=dm-0
ino=36919 scontext=root:system_r:hostname_t:s0
tcontext=root:object_r:etc_mail_t:s0 tclass=file
avc:  denied  { read } for  pid=7263 comm="hostname" name="cf.m4" dev=dm-2
ino=358446 scontext=root:system_r:hostname_t:s0
tcontext=system_u:object_r:usr_t:s0 tclass=file
avc:  denied  { read } for  pid=7263 comm="hostname" name="cfhead.m4" dev=dm-2
ino=358447 scontext=root:system_r:hostname_t:s0
tcontext=system_u:object_r:usr_t:s0 tclass=file

avc:  denied  { read } for  pid=10078 comm="mount" name="[123574]" dev=pipefs
ino=123574 scontext=user_u:system_r:mount_t:s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file
Comment 1 Orion Poplawski 2006-03-22 12:13:46 EST
Here's what I get now on a fresh FC5 system:

Mar 21 16:53:09 sombrero kernel: audit(1142985116.297:2): avc:  denied  { search
} for  pid=481 comm="pam_console_app" name="var" dev=hda2 ino=608609
scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255
tcontext=system_u:object_r:file_t:s0 tclass=dir

Mar 21 16:53:56 sombrero kernel: audit(1142985236.296:257): avc:  denied  {
getattr } for pid=2432 comm="hald" name="/" dev=hda6 ino=2
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:user_home_t:s0
tclass=dir

/dev/hda6 on /export type ext3 (rw)
drwxr-xr-x  root     root     system_u:object_r:user_home_t    /export

This is where we put user data on our laptops.  I realize this is non-standard,
but would like to know an easy way to shut hald up about this.

Mar 21 16:54:00 sombrero kernel: audit(1142985240.012:264): avc:  denied  {
name_connect } for  pid=2497 comm="hostname" dest=111
scontext=system_u:system_r:hostname_t:s0
tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket
Mar 21 16:54:00 sombrero kernel: audit(1142985240.012:265): avc:  denied  {
name_bind } for  pid=2497 comm="hostname" src=977
scontext=system_u:system_r:hostname_t:s0
tcontext=system_u:object_r:reserved_port_t:s0 tclass=tcp_socket

These look to be from running cfengine:

Mar 21 17:04:28 sombrero kernel: audit(1142985868.244:307): avc:  denied  { read
} for  pid=3603 comm="hostname" name="[28924]" dev=pipefs ino=28924
scontext=user_u:system_r:hostname_t:s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file
Mar 21 17:04:28 sombrero kernel: audit(1142985868.244:308): avc:  denied  {
write } for pid=3603 comm="hostname" name="[30792]" dev=pipefs ino=30792
scontext=user_u:system_r:hostname_t:s0 tcontext=user_u:system_r:unconfined_t:s0
tclass=fifo_file
Mar 21 17:04:28 sombrero kernel: audit(1142985868.244:309): avc:  denied  {
write } for pid=3603 comm="hostname"
name="cf_sombrero_cora_nwra_com_2006-03-21--17-00-05" dev=hda3 ino=4117
scontext=user_u:system_r:hostname_t:s0 tcontext=user_u:object_r:var_t:s0 tclass=file
Mar 21 17:04:28 sombrero kernel: audit(1142985868.244:310): avc:  denied  { read
} for  pid=3603 comm="hostname" name="sendmail.mc" dev=hda2 ino=835569
scontext=user_u:system_r:hostname_t:s0 tcontext=system_u:object_r:etc_mail_t:s0
tclass=file
Mar 21 17:04:28 sombrero kernel: audit(1142985868.244:311): avc:  denied  { read
} for  pid=3603 comm="hostname" name="cf.m4" dev=hda2 ino=705559
scontext=user_u:system_r:hostname_t:s0 tcontext=system_u:object_r:usr_t:s0
tclass=file
Mar 21 17:04:28 sombrero kernel: audit(1142985868.244:312): avc:  denied  { read
} for  pid=3603 comm="hostname" name="cfhead.m4" dev=hda2 ino=705560
scontext=user_u:system_r:hostname_t:s0 tcontext=system_u:object_r:usr_t:s0
tclass=file
Mar 21 17:04:29 sombrero kernel: audit(1142985869.632:313): avc:  denied  { read
} for  pid=3625 comm="restorecon" name="[28924]" dev=pipefs ino=28924
scontext=user_u:system_r:restorecon_t:s0
tcontext=system_u:system_r:crond_t:s0-s0:c0.c255 tclass=fifo_file
Mar 21 17:04:29 sombrero kernel: audit(1142985869.636:314): avc:  denied  {
write } for pid=3625 comm="restorecon"
name="cf_sombrero_cora_nwra_com_2006-03-21--17-00-05" dev=hda3 ino=4117
scontext=user_u:system_r:restorecon_t:s0 tcontext=user_u:object_r:var_t:s0
tclass=file


Mar 21 18:47:16 sombrero kernel: audit(1142992036.916:573): avc:  denied  {
execheap } for  pid=31845 comm="ld-linux.so.2"
scontext=system_u:system_r:crond_t:s0 tcontext=system_u:system_r:crond_t:s0
tclass=process

saw about 10 of these until Mar 21 19:18:44 but then no more.
Comment 2 Daniel Walsh 2006-04-03 12:26:49 EDT
You have a badly labeled system,  You need to relabel

touch /.autorelabel
reboot
Comment 3 Orion Poplawski 2006-04-03 13:58:46 EDT
This is now a fully up-to-date FC5 system, including updates-testing.

Did a relable, still have:

lots of:

Apr  3 11:47:59 sombrero kernel: audit(1144086400.680:2): avc:  denied  { search
} for  pid=495 comm="pam_console_app" name="var" dev=hda2 ino=608609
scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255
tcontext=system_u:object_r:file_t:s0 tclass=dir

This looks like the mount point on the root filesystem for the /var directory.
/dev/hda2 on / type ext3 (rw)

hald is a little different:

Apr  3 11:48:36 sombrero kernel: audit(1144086516.387:258): avc:  denied  {
getattr } for  pid=2428 comm="hald" name="/" dev=hda6 ino=2
scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:default_t:s0
tclass=dir

New:

Apr  3 11:48:22 sombrero kernel: audit(1144086494.074:257): avc:  denied  {
setattr } for  pid=2215 comm="cupsd" name="cups" dev=hda3 ino=38818
scontext=system_u:system_r:cupsd_t:s0-s0:c0.c255
tcontext=system_u:object_r:cupsd_var_run_t:s0 tclass=dir

Comment 4 Daniel Walsh 2006-04-03 17:37:35 EDT
Not sure how to fix it but you need a label on /var before /var is mounted??

restorecon /var in rc.sysinit would fix it, did you install it this way?

hal looks like it is strolling through the / dir?

Comment 5 Orion Poplawski 2006-04-04 11:19:59 EDT
System was installed via kickstart with /var specified as a separate partition:

part /boot --fstype ext3 --size=50
part / --fstype ext3 --size=5000
part /var --fstype ext3 --size=512
part swap --recommended
part /export --fstype ext3 --size=100 --grow

Seems like any needed labeling should have been done at install time.

Tried:

# Clean up SELinux labels
if [ -n "$SELINUX_STATE" ]; then
   restorecon /etc/mtab /etc/ld.so.cache /etc/blkid.tab /etc/resolv.conf
>/dev/null 2>&1
fi

if [ -n "$SELINUX_STATE" ]; then
        /sbin/restorecon -v /var
fi

and it changed it from file_t to var_t.  Then a final reboot and the pam_console
messages go away.  Still seems odd that pam_console.app is holding on the the
/var mountpoint even after /var is mounted though....


I suspected that hal is looking at all mounted filesystems, but it might be
reading /.  On another system with:

/dev/mapper/rootvg-data1 on /export/data1 type ext3 (rw)
# ls -Za /export
drwxr-xr-x  root     root     system_u:object_r:user_home_t    .
drwxr-xr-x  root     root     system_u:object_r:root_t         ..
drwxrwxr-x  root     cora     system_u:object_r:user_home_t    data1

I see:
audit(1144163937.050:7): avc:  denied  { search } for  pid=2436 comm="hald"
name="export" dev=dm-0 ino=118785 scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:user_home_t:s0 tclass=dir
# ls -id /export
118785 /export

as opposed to looking in /export/data1.

What is hald allowed to search?  What is an appropriate label for /export?
Comment 6 Daniel Walsh 2006-04-06 15:08:19 EDT
Not sure what you are putting in /export  If it is a homedir.  home_root_t might
be correct.
Dan
Comment 8 Daniel Walsh 2006-05-05 11:05:37 EDT
Closing as these have been marked as modified, for a while.  Feel free to reopen
if not fixed
Comment 9 Orion Poplawski 2006-05-11 11:23:34 EDT
I'd like to deal with the hald /export issue:

- On desktop systems we mount the extra space on the disk as /export/data1.  Any
additional disks in the system we be something like /export/data2 and so on. 
This are just general storage areas for users' data.
- On laptops the extra space is mounted as /export and user's home directories
are in /export/home.  Some local stuff goes in /export/local (get's symlinked to
/opt/local when off of our network).

On desktops we get the following avcs:

audit(1147105371.159:224): avc:  denied  { search } for  pid=2392 comm="hald"
name="export" dev=dm-0 ino=73729 scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:default_t:s0 tclass=dir

with default labeling, or:

audit(1147356243.461:294): avc:  denied  { search } for  pid=2428 comm="hald"
name="export" dev=dm-0 ino=73729 scontext=system_u:system_r:hald_t:s0
tcontext=system_u:object_r:home_root_t:s0 tclass=dir

with labeling it as home_root_t.

This is with selinux-policy-targeted-2.2.38-1.fc5 and after doing a /.autorelabel

We saw something similar with the laptops, but I'm not seeing it now and I don't
know why.
Comment 10 Daniel Walsh 2006-05-23 16:49:42 EDT
Fixed in selinux-policy-2.2.42-2.fc5

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