Bug 189960

This is strange since I see no duplicates???

# echo "/lost+found/"|grep "lost+found"
/lost+found/
# echo "/lost+found/"|grep "lost+found/.*"
/lost+found/
# echo "/lost+found/"|grep "lost+found/.+"
# 

I think the problems is that those ".*" patterns should be replaced by ".+"
since ".*" collapses to nothing when SELinux is looking at "/lost+found/" (for
example). You then do have 2 matching rules.

I've just done another, "yum -y update", and I'm getting the same errors again.
Additionally, I now get an error about 'base.pp':

<snip>
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications
for /var/lost\+found.
/etc/selinux/targeted/contexts/files/file_contexts: Multiple same specifications
for /usr/lost\+found.
  Updating  : selinux-policy-targeted      ####################### [ 4/12] 
semodule:  Could not read file 'base.pp':
  Updating  : pygtk2-devel                 ####################### [ 5/12] 
  Updating  : system-config-date           ####################### [ 6/12] 
</snip>

I should point out that I haven't touched any of the SELinux policy files.

 for i in `locate -r "/base.pp$"`
> do
> ls -al $i
> done
-rw------- 1 root root 4448463 Apr 25 09:20
/etc/selinux/targeted/modules/active/base.pp
-rw------- 1 root root 4448463 Apr 12 08:26
/etc/selinux/targeted/modules/previous/base.pp
-rw-r--r-- 1 root root 4359040 Apr 21 12:05 /usr/share/selinux/targeted/base.pp

# for i in `locate -r "/base.pp$"`; do ls -alZ $i; done
-rw-------  root     root     system_u:object_r:semanage_store_t
/etc/selinux/targeted/modules/active/base.pp
-rw-------  root     root     user_u:object_r:semanage_store_t
/etc/selinux/targeted/modules/previous/base.pp
-rw-r--r--  root     root     user_u:object_r:user_home_t     
/usr/share/selinux/targeted/base.pp
# sestatus -v
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 20
Policy from config file:        targeted

Process contexts:
Current context:                user_u:system_r:unconfined_t
Init context:                   system_u:system_r:init_t
/sbin/mingetty                  system_u:system_r:getty_t
/usr/sbin/sshd                  system_u:system_r:unconfined_t:SystemLow-SystemHigh

File contexts:
Controlling term:               user_u:object_r:devpts_t
/etc/passwd                     system_u:object_r:etc_t
/etc/shadow                     system_u:object_r:shadow_t
/bin/bash                       system_u:object_r:shell_exec_t
/bin/login                      system_u:object_r:login_exec_t
/bin/sh                         system_u:object_r:bin_t ->
system_u:object_r:shell_exec_t
/sbin/agetty                    system_u:object_r:getty_exec_t
/sbin/init                      system_u:object_r:init_exec_t
/sbin/mingetty                  system_u:object_r:getty_exec_t
/usr/sbin/sshd                  system_u:object_r:sshd_exec_t
/lib/libc.so.6                  system_u:object_r:lib_t -> system_u:object_r:lib_t
/lib/ld-linux.so.2              system_u:object_r:lib_t -> system_u:object_r:ld_so_t

I haven't seen this behavior myself, but it sounds like your policy store is
corrupted in some manner.
Try re-installing the policy, e.g.
# /usr/sbin/semodule -b /usr/share/selinux/targeted/base.pp

Also, what local customizations do you have, e.g. what .local files do you have
under /etc/selinux/targeted/modules/active, and what do they contain?

I've run "/usr/sbin/semodule -b /usr/share/selinux/targeted/base.pp", but
although it regenerated /etc/selinux/targeted/contexts/files/file_contexts, I
still have the duplication and the erorr messages.

I have no .local files, and have made zero modifications to SELinux AFAIK.

Can you tar up your /etc/selinux/targeted directory and attach it?
I'd like to see the full tree and its contents.  I still don't understand why
I'm not seeing it here on FC5.  Is anyone else?

Created attachment 128473 [details]
tgz of /etc/selinux/, as requested.

Phew! After a half dozen attempts, please find attached the contents of my
/etc/selinux/ directory.

Ok, the problem lies in file_contexts.homedirs, which contains the duplicate
entries.  This file is generated by genhomedircon from the homedir_template file
and information it extracts about user home directories on the system. 
homedir_template includes a HOME_ROOT/lost\+found entry, apparently to deal with
/home/lost+found and any other home directory partitions, but apparently one of
the values that genhomedircon is substituting for HOME_ROOT is /var and /usr,
which means it is finding home directories with those prefixes in passwd for
entries it thinks are legitimate users (heuristically determined based on uid >
starting_uid, shell in set of valid shells).
Needs to exclude these patterns if they already exist in file_contexts.

If you have service accounts with UID > 500 and login shells that are not
/bin/false or /sbin/nologin this could cause a problem.  If so you should report
this as a bug to the provider of these services.

OK, I've identified the problem account, and fixed it as per instructions above.
However, I'm having major boot problems right now. The cause would appear to be...

# ls -ldZ /root /home /usr /var
drwxr-xr-x  root     root     system_u:object_r:home_root_t    /home
drwxr-x---  root     root     root:object_r:user_home_dir_t    /root
drwxr-xr-x  root     root     system_u:object_r:home_root_t    /usr
drwxr-xr-x  root     root     system_u:object_r:home_root_t    /var

I've tried a full FS relabel, but my policy still has duplicate entries. I've
also tried running "semodule -b base.pp", and "semodule -B", but both return "1"
with no messages.

Clearly /var and /usr are incorrectly labelled, but it looks too like /home and
/root's context are swapped - surely /root should be labelled home_root_t and
/home user_home_dir_t???

Help!

Firstly, strike my question about /root and /home contexts being swapped. I
understand what's going on there now :-)

Secondly - I had _another_ odd user with a home dir under /usr which was causing
the other SELinux messages.

To resolve the issue, I ran:

userdel -r <problem_user>
genhomedircon
semodule -b base.pp
touch /.autorelabel
reboot
reboot
reboot
reboot

... and then checked using "fixfiles check" that everything looked ok. As shown,
worryingly it took 4 reboots to get my machine booting properly again.

I'm not sure if this was SELinux, but it just hung starting seemingly random
daemons. Also, I have seen bizareness relating to the graphical boot where even
when the SELinux relabel was going on, the boot sequence merrily attempted to
start the X Server, but all it displayed was a black screen with an X-shaped
cursor. Switching back to virtual console 1 allowed me to observe that the
relabel had finished. However, the system just sat there doing nothing. It
wasn't hung (caps lock light OK, etc), but in the end I had to reboot a few
times and then it seemed happy. I'll go and run smartctl I think just in case...).

I suspect that the problem I had with 2 users who had been automatically added
to my system by rpm installs might be a problem for others. Is there any way we
can display a helpful warning message when genhomedircon finds system accounts
with UID > 500 and home dir not beginning "/home"? Maybe a big flashing message
when the machine boots or summut?

This problem has caused me a great deal of pain and wasted time, although the
silver lining is that I've learned a bit more about SELinux in the process. I
also greatly appreciate your help guys.

James.

Hmm...genhomedircon already does a check of each user to see if their home
directory already has a conflicting entry in the base file contexts
configuration, and if so, won't add the entry for the user's home directory
(getHomeDirs).  But possibly this isn't being done for the home roots (i.e. the
directories containing user home directories, like /home)?  Otherwise, I would
have expected it to skip /usr and /var.  Dan?

Ok, simple test case:
# useradd -d /usr/joe joe
# /usr/sbin/genhomedircon

Adds /usr entries to file_contexts.homedirs.  Not good.
Meanwhile, base file_contexts has:
/usr/.*    system_u:object_r:usr_t:s0
/usr -d system_u:object_r:usr_t:s0

checkExists() looks broken.

Added bit more detail to Summary to help others searching for similar problems

Created attachment 128778 [details]
Patch for genhomedircon from Dan Walsh of Red Hat

This patch fixes a bug in the genhomedircon logic that is supposed to prevent
adding entries to file_contexts.homedirs that conflict with already existing
entries in the base file_contexts.  After applying this patch, useradd -d
/usr/joe joe; /usr/sbin/genhomedircon correctly warns about the conflict and
skips that directory rather than adding it.
This needs to go into a FC5 update for policycoreutils.  Patch upstreamed.

Hi Guys,

I'm still having problems. I've done some hw checks, and the box seems ok in
that respect. However, it keeps hanging on boot at "Starting eth0". I have to
Control-C it, which occasionally generates an "interrupted system call" message.
At shutdown, it also hangs (generally shutting down cpuspeed). This time,
Control-C doesn't help, and I've gotta reach for the power button.

If I boot into single-user mode, most things seem to work, but the network is
odd. I can manually start it ("service network start"), and it always start fine
(unlike the non-interactive network start). I can ping things (ICMP), I can do
host look-ups, but I cannot reliably use TCP packets. 'curl' hangs - if I
ltrace/strace it, the last call before my SIGINT (Control-C) is gettimeofday().
ssh doesn't work either - it hangs again, but in select() on the fd used for the
network connection). Bizarrely, "telnet <machine> 22" does make the connection
to the remove machine. Distressingly yum doesn't work either... ;-(

I should point out that the firewall is switched off, and there are no errors on
the network interface.

I cannot see anything juicy in /var/log, and all the FS's are labelled correctly
now AFAICS. Any ideas?

Thanks in advance.

James.

Are you sure it is SELinux-related?  Does it still happen if you setenforce 0 or
boot with the enforcing=0 kernel boot parameter?

"setenforce permissive" still gives me the problem. All I know is that my system
worked fine before I removed my 2 bogus users, and ran genhomedircon / relabel, etc.

I'm really scratching around for clues right now. Unfortunately, this box my
main w/s.

James.

Fixed in  policycoreutils-1.30.8-1.fc5

Um. Thing is, my network is hosed. Is there a simple workaround for my system?
Can I disable something some SELinux modules or something?

If not, I'll have to attempt to copy the latest policycoreutils using netcap
over UDP ;-(

netcat that is :-)

Try booting with enforcing=0 (or with SELINUX=permissive in
/etc/selinux/config).  That ensures that the entire bootup is done permissively,
not just switching later via setenforce.

If that doesn't work, try booting with selinux=0 (or with SELINUX=disabled in
/etc/selinux/config) and see if that makes any difference.  That disables
SELinux altogether.

If not, then I think that this is some other network problem.  Check your
network configuration and do general network troubleshooting.

dang - "nc -u" doesn't work either. If I boot with a Knoppix CD, my network is
fine, so the hw is not at fault. The routing table is fine, the interface is up,
and there are no errors.

If I boot with enforcing=0 and SELINUX=permissive in /etc/sysconfig/selinux
(well, why not? :-), sestatus shows:

SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   permissive
Mode from config file:          permissive
Policy version:                 20
Policy from config file:        targeted

Additionally, the machine now boots with no problems (it doesn't hang when
starting eth0), so I suspect there is something SELinux-related going on here.

My curl still hangs (calling 2 x gettimeofday() and poll) in a loop. My ftp
session hangs on read() and my ssh hangs on poll(), so still network problems.

I think you want to file a new bug against the kernel.

OK. Not quite sure what detail to include though - I've got very little hard
data to present here, which presumably is going to make it very difficult for
you guys to recreate+fix. I have another box running FC5 which doesn't suffer
from the same problem, but it didn't have the erroneous users in /etc/passwd.
I'll keep searching for more clues, but I'm really unsure what is going on.

Hopefully when policycoreutils-1.30.8-1.fc5 hits the yum mirrors (doesn't seem
to be available yet), the problem will go away (I can cut a CD and update the
package manually).

I don't think the updated policycoreutils is going to make any difference, and
you can already apply the patch I attached for genhomedircon locally if you
want.  That only avoids getting the bogus entries in file_contexts.homedirs, but
you already "solved" that by removing the offending pseudo users.

Sounds more like a network driver bug to me than anything SELinux related. 
Maybe you happened to update your kernel in the same time frame?

Yup - this is a kernel bug. I've booted back to kernel-2.6.15-1.2054_FC5, and
the networking works fine. I'll raise another bugzilla on kernel. This bug can
now be closed IMHO. Thanks for your help!

James.