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.

You have a badly labeled system,  You need to relabel

touch /.autorelabel
reboot

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

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?

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?

Not sure what you are putting in /export  If it is a homedir.  home_root_t might
be correct.
Dan

Closing as these have been marked as modified, for a while.  Feel free to reopen
if not fixed

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.

Fixed in selinux-policy-2.2.42-2.fc5