From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041111 Firefox/1.0 Description of problem: Upgrading to selinux-policy-targeted-1.17.30-2.80 causes every use of rpm to report: WARNING: Multiple same specifications for /var/lost\+found(/.*)?. WARNING: Multiple same specifications for /var/\.journal. This is because /etc/selinux/targeted/contexts/files/file_contexts in fact contains two identical entries for those two patterns. Version-Release number of selected component (if applicable): selinux-policy-targeted-1.17.30-2.80 How reproducible: Always Steps to Reproduce: 1. Upgrade to selinux-policy-targeted-1.17.30-2.80 2. Use rpm to install or upgrade some package. 3. Actual Results: I got the described warnings. Expected Results: No warnings. Additional info:
This is still true of the just released selinux-policy-targeted-1.17.30-2.83.
Do you have users accounts in /var? Dan
No, but I administer my machine via sudo. Could upgrading selinux-policy-targeted via "sudo rpm" cause this problem?
Do you have selinux-policy-targeted-sources installed? Could you attach your /etc/selinux/targeted/contexts/files/file_context file Dan
Created attachment 111531 [details] file_contexts file with multiple same /var patterns Yes, I have selinux-policy-targeted-sources installed. I am attaching the file_contexts file from the affected machine. I see that an attempt is being made to extract home directories from /etc/passwd. In my /etc/passwd there are entries like this (changed slightly due to my paranoia): gopher:x:10:20:gopher:/var/gopher:/sbin/nologin enable:x:30:40:Enable CVS User:/projects/enable:/bin/tcsh apache2:x:50:60:Apache Web Server:/usr/local/etc/httpd:/bin/tcsh which is how those directories are getting picked up, apparently.
Could you change the shell accounts to /sbin/nologin I don't think you want to login to those accounts. Afterwards run make -C /etc/selinux/targeted/src/policy reload Does that remove the duplicates
Unfortunately, I can't do that. I'm just a Joe User here, although the sysadmins let me upgrade packages with sudo. I'll have to ask the sysadmins to do this. The answer might be no if they think they have a good reason for those shells. In any case, can't you filter /var out of the list of paths generated from /etc/passwd? That would prevent this from happening to other people in a similar situation.
I have a somewhat related problem on FC3. At one point, I installed netdump-server (recently I uninstalled it, but that doesn't affect this issue). It has this nifty bit of code snipped from its %pre script: /usr/sbin/useradd -c "Network Crash Dump user" -r -u 34 -g netdump \ -s /bin/bash -r -d /var/crash netdump 2>/dev/null || : Sure enough, in /etc/passwd I have: netdump:x:34:34:Network Crash Dump user:/var/crash:/bin/bash and in /etc/selinux/targeted/contexts/files/file_contexts I have: /var/[^/]+ -d system_u:object_r:user_home_dir_t This caused several daemons (named, syslogd, portmap, ypbind, ntpd) to get avc denied errors on reboot, e.g.: Mar 2 18:03:49 geyser kernel: audit(1109815429.248:0): avc: denied { search } for pid=3399 exe=/sbin/syslogd name=var dev=dm-0 ino=4194433 scontext=user_u:system_r:syslogd_t tcontext=system_u:object_r:home_root_t tclass=dir Given that I trustingly updated the policy rpm Saturday, and my logs got rotated Sunday, my new logs were empty until I put the machine in permissive mode this evening. More seriously, I rebooted the machine remotely this evening (but sitting in the same building, so I was able to run over and debug), leaving the machine in enforcing mode, and it took several minutes longer than normal to come up fully, I suppose because e.g. sylogd was spinning until timeout. I've removed all traces of netdump from /etc/{passwd,shadow,group,gshadow}, ran the 'make' you suggested above. After reboot I still got these errors. Tracing this back through the various layers, I see that's because we are using NIS, and NIS has a user 'postman' with home /var/postman. Is HOME_ROOT a new feature in selinux, or in the targeted policy, as it seems? It seems to me its presence carries a big risk: Anyone or any rpm that creates a user with a valid shell but an inopportune home directory, may cause avc denied failures, perhaps severe ones. You've suddenly saddled sysadmins, rpm authors, and authentication database maintainers with a new, critical responsibility, one that I wasn't aware of. Should I have been aware of it? Whaddya think, Dan? Hope I'm not blowing this out of proportion; I'm a capable sysadmin, but a relative newbie to selinux.
Ok can you run genhomedircon and take a look at /etc/selinux/targeted/contexts/files/file_context? That should remove the secondary definition of /var? We have a newer version of genhomedircon in rawhide that I will begin to back port since this seems to be a larger problem than first thought. Some users might have a legitimate reason for putting users in /var and the scripts should be able to handle this. Dan
I wasn't sure what parameters to pass to genhomedircon, so from /etc/selinux/targeted, I did this: genhomedircon src contexts/files/file_contexts The output that produces does not, in fact, have the duplicate /var patterns. While checking on this, I also discovered that load_policy has dumped core into /etc/selinux/targeted/src/policy every time I have logged in from the console since Feb. 18, the day I made the initial report. Since that is a protected directory, I didn't know those core files were there until I started poking around with sudo. The backtraces all look like this: (gdb) bt #0 0x006fe7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 #1 0x0073e955 in raise () from /lib/tls/libc.so.6 #2 0x00740319 in abort () from /lib/tls/libc.so.6 #3 0x00737f41 in __assert_fail () from /lib/tls/libc.so.6 #4 0x004d3570 in security_get_boolean_names (names=0x0, len=0xbfe22bfc) at booleans.c:48 #5 0x08048bc9 in main (argc=2, argv=0xbfe22d04) at load_policy.c:96 #6 0x0072be33 in __libc_start_main () from /lib/tls/libc.so.6 #7 0x08048891 in _start () I should note that I have all the selinux packages installed, but it is currently turned off at boot time.
Could you open a separate bug on this? Otherwise it will get lost in the shuffle. Thanks Dan
I now realize that netdump-server would not cause a problem because its custom user is uid 34 < 100. I'm still getting a problem because we have in NIS: postman:*LK*:30020:111:Postman user:/var/postman:/bin/sh I don't know if this configuration is correct or desireable any longer, but it is our legacy situation. To follow up on your latest test request, I just now did: [root@geyser files]# pwd /etc/selinux/targeted/contexts/files [root@geyser files]# rpm -q selinux-policy-targeted selinux-policy-targeted-1.17.30-2.85 [root@geyser files]# genhomedircon ../../src file_contexts |grep var | head -6 # this is /var/run/utmp. /var -d system_u:object_r:home_root_t /var/[^/]+ -d system_u:object_r:user_home_dir_t /var/[^/]+/.+ system_u:object_r:user_home_t # /var /var(/.*)? system_u:object_r:var_t So yeah, I still have a problem. :) A sane, knowledgeable sysadmin would set selinux in permissive mode before updating policy, then see what errors (if any) are generated upon reboot after policy update. And that sysadmin would catch things like this, presumably. But a lot of us aren't that knowledgeable yet about selinux, so might get bitten like I did. No damage (except DoS), but a bit frustrating. I suppose remote admins might have more trouble.
Created attachment 111786 [details] fix home_root_t logic in genhomedircon Here is my first hack to fix the logic in /usr/sbin/genhomedircontexts against policycoreutils-1.18.1-4
Eric, your patch still created a home_root_t entry for /var in my environment. Is there something I can do to give you more detailed feedback?
Can you give me a copy of /etc/passwd (relevant line) /etc/default/useradd /etc/libuser.conf? And let me know how you regenerate? Did you use the makefile or run genhomedircon by hand?
Created attachment 111827 [details] A cleanup on the last patch. Should be little more maintainable This patch watchs both /etc/libuser.conf and /etc/login.defs for minimum login. It removes some uses of sed since the create error checking problem and instead uses the python internal re module. This patch also fixes the logic in the last patch where a user could define HOME=/var in /etc/default/useradd and the /var directory would become improperly labeled.
Created attachment 111835 [details] newest iteration
Created attachment 111836 [details] Hopefully last???? Found that a stategically placed comment in /etc/default/useradd, /etc/libuser.conf, or /etc/login.defs could cause the script to fail.
*** Bug 150466 has been marked as a duplicate of this bug. ***