Description of problem: NIS provided users can't login to selinux enabled system Version-Release number of selected component (if applicable): selinux-policy-3.3.1-55.fc9.noarch pam-1.0.1-2.fc9.i386 ypbind-1.20.4-4.fc9.i386 How reproducible: Always Steps to Reproduce: 1. Install new Fedora 9 system, update to current. 2. Set up for NIS provided users (NFS provided home directories) 3. Try to login Actual results: Login fails. With selinux set to enforcing, no errors in audit.log; with it set to permissive I get errors like in the attached extract of audit.log. Expected results: Users able to login. Additional info: I've tried a couple of selinux-policy updates from testing (and even from rawhide) - 3.3.1-59, 3.3.1-62 and 3.4.1-2 (with it's required update to checkpolicy). They did not solve the problem.
Created attachment 308394 [details] audit.log
With 3.3.1-62 installed pleas update the AVC's that you are seeing.
Created attachment 308492 [details] audit.log enforcing This is the audit log with selinux-policy 3.3.1-62, with selinux set to enforcing.
Created attachment 308493 [details] audit.log permissive This is the audit.log with selinux-policy 3.3.1-62, set to permissive.
Both of the above log file extracts were collected after having run semodule -DB (otherwise much less info is recorded).
setsebool -P allow_ypbind=1 Should allow ypbind users to login.
This is with allow_ypbind=1 set. I have also tried setting to 0, relabeling, then setting back to 1 and relabeling.
Do you have use_nfs_home_dirs boolean turned on? setsebool -P use_nfs_home_dirs=1 What does audit2why -i /var/log/audit/audit.log Show?
Created attachment 308867 [details] results of audit2why
Yes, use_nfs_home_dirs is turned on. I've attached the results of audit2why -i /var/log/audit/audit.log; it looks like most (if not all) the entries are like the following: type=AVC msg=audit(1213130552.742:44620): avc: denied { noatsecure } for pid=1040 comm="bash" scontext=system_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access.
I've just updated to the current Fedora 9 packages (kernel-2.6.25.6-55.fc9.i686, ypbind-1.20.4-5.fc9.i386, selinux-policy-targeted-3.3.1-64.fc9.noarch, selinux-policy-3.3.1-64.fc9.noarch). No change.
This does not make sense because when I turn on allow_ypbind this works. Pumping your avc's through audit2why says that these rules would be allowed by current polcicy. So you are sure allow_ypbind is turned on?
Created attachment 309501 [details] audit2allow log Absolutely. getsebool allow_ypbind returns "allow_ypbind --> on". audit2why on the machines in question here returns a whole lot of "denied"... I'm guessing now that the selinux policies on these machines are very screwed up. I just ran audit2allow against one of them - I'll attach the results. There appears to be more than just the ypbind problem. My guess is that somehow, the policy rules are missing.
Can you download a policy and force an update? I just released policy 68 to testing try this out and see if the policy gets updated properly.
I got the following errors when updated selinux-policy-targeted: libsemanage.semanage_fc_sort: WARNING: semanage_fc_sort: Incomplete context. libsemanage.semanage_fc_sort: WARNING: semanage_fc_sort: Incomplete context. libsemanage.semanage_fc_sort: WARNING: semanage_fc_sort: Incomplete context. libsepol.context_from_record: type prelude_lm is not defined libsepol.context_from_record: could not create context structure libsepol.context_from_string: could not create context structure libsepol.sepol_context_to_sid: could not convert system_u:object_r:prelude_lm to sid invalid context system_u:object_r:prelude_lm libsemanage.semanage_install_active: setfiles returned error code 1. semodule: Failed! I'll try again by removing the policy packages entirely, then re-installing.
Oh well, that didn't help either. Nor did re-labeling after having applied this latest policy.
Sorry 68 was broken, Try 69 or 70
Where do I get one of those versions? They don't seem to be in the updates-testing repo.
69 should be released. 70 is in koji. I will building a new test release by Friday.
OK, I've installed 69. Unfortunately, it hasn't resolved the problem. The error messages remain the same.
Peter, just out of curiosity, ls -l /etc/selinux/targeted/policy
ls -l /etc/selinux/targeted/policy/ gives: total 2220 -rw-r--r-- 1 root root 2266448 2008-06-25 09:45 policy.23
You have got me stumped. Steve do you have any ideas?
I'm a little late to the party - can someone summarize the current situation? From the original audit.log, I see that unix_chkpwd was denied the ability to bind to a hi reserved port (likely required to communicate with the NIS server) and it was denied the ability to access selinuxfs (possibly required if it makes any permission checks or does anything with contexts). Other possibilities: The typically denied permissions (noatsecure, rlimitinh, siginh) on a domain transition could be preventing passing of state to unix_chkpwd or helpers. So you might want to allow noatsecure in particular from the calling domain to the chkpwd domain and see if that helps. You should be able to generate a local policy module with the allow rules you want to try, insert it and try again immediately w/o waiting on a new policy package. audit2allow -a -M mymodule and semodule -i mymodule.pp But I'd be more selective in what you put into mymodule.te, or prune the output from audit2allow and rebuild it (make -f /usr/share/selinux/devel/Makefile mymodule.pp).
Current situation is that the system was a clean Fedora 9 build. No local users (other than the system users, of course); user info provided by NIS, home directories provided by NFS. It's been updated to current (so, kernel-2.6.25.9-76.fc9.i686, selinux-policy-3.3.1-72.fc9.noarch, selinux-policy-targeted-3.3.1-72.fc9.noarch, ypbind-1.20.4-6.fc9.i386). The booleans allow_ypbind and use_nfs_home_dirs are both on. The problem is that users cannot log in, unless I disable SELinux entirely (setenforce 0). Mr. Walsh says this works fine for him, so I'm trying to figure out what I broke, and how. (Incidentally, this has happened to all three F9 machines I've tried to set up - two x86_64 and one i386 in case it matters.) I've tried generating the local policy as you suggested, but it doesn't help. I'll attach the audit log from the attempt.
Created attachment 310842 [details] audit.log Cut of audit.log from when I tried to generate and load a local policy, after having created it with audit2allow -a -M mymodule; semodule -i mymodule.pp
Hmmm...I see a net_bind_service denial still. Try appending the following to mymodule.te: allow system_chkpwd_t self:capability net_bind_service; Then rebuild it as follows: make -f /usr/share/selinux/devel/Makefile mymodule.pp (presumes selinux-policy-devel is present) or Then re-insert it: semodule -i mymodule.pp
[root@agh ~]# make -f /usr/share/selinux/devel/Makefile mymodule.pp Compiling targeted mymodule module /usr/bin/checkmodule: loading policy configuration from tmp/mymodule.tmp mymodule.te":97:ERROR 'unknown class capability used in rule' at token ';' on line 1099: allow system_chkpwd_t self:capability net_bind_service; /usr/bin/checkmodule: error(s) encountered while parsing configuration make: *** [tmp/mymodule.mod] Error 1
Add: class capability { net_bind_service }; inside the require { } block in mymodule.te.
OK, that permits me to compile and load the module, and finally to log in. Now the question is what did I do to break this in the first place? And why did reloading (updating)/re-installing the policies not fix it? Also, will there be an updated package with this fix released?
So this indicates that chkpwd had to bind to a high reserved port in order to perform the NIS query. Which doesn't seem to be allowed by current policy AFAICS. The two relevant allow rules seem to be allow <domain> hi_reserved_port_t:udp_socket name_bind; allow <domain> self:capability net_bind_service; I suspect that if you remove all the other rules that don't match the above pattern from mymodule.te and rebuild and reload it, things will still work. Dan - why isn't this allowed? I'm not sure how the client-side yp code chooses its port, but it seems like one could easily run into this situation if it is pseudo random or just looks for the first available one within a range and happens to fall into that range.
OK, I stripped mymodule.te as you suggested, rebuilt and reloaded it. You're correct, I can still log in, although there are still copious avc denied errors in audit.log. Mind you, I ran semodule -DB right after inserting the new policy module. If you think it's helpful, I can post the log segment.
That's to be expected - there is a reason why we have dontaudit rules in the policy. semodule -B to rebuild with dontaudits included. Ok, so we know definitively that the problem lies in the hi_reserved_port_t:udp_socket name_bind permission and net_bind_service capability, and that is what Dan needs to make sure gets included in the allow_ypbind conditional. Or figure out a way to prevent yp client code from using hi reserved ports in the first place.
interface(`nis_use_ypbind_uncond',` gen_require(` type var_yp_t; ') dontaudit $1 self:capability net_bind_service; It has always been like this. We run tons of nis here and I have never seen this before. I will allow it.
Fixed in selinux-policy-3.3.1-76
Follow up: kernel 2.6.24 got source port randomization for UDP. That could yield this behavior, where NIS client code was previously binding to a low reserved port but the randomization switched it to a high port.
Actually, I take that back - that would only affect port selection for non-reserved ports out of the local port range I believe. Looking at the nis code in glibc, it appears to always call bindresvport first with a 0 port value, and that always tries to allocate from the hi reserved port range. So I'm not sure why this hasn't been a problem in the past.
Dan - I'm sorry, but selinux-policy-3.3.1-78 does not fix this for me. I thought it had, and the test system that I built and installed the local module on (see comment 32) still works, but the system I was originally seeing the problem on and now another new system I've just built are still not able to authenticate NIS provided users. I've had to keep SELinux disabled on those systems. Two questions: 1) What am I doing wrong? 2) Does having installed a locally built selinux module make it stick around permanently, even after having updated the selinux policy? If so how can I remove it again? Thanks...
semodule -r mymodule will remove the custom module. Could you show me your latest avc messages with 79 installed.
Created attachment 312933 [details] audit.log with SELinux enabled
Created attachment 312934 [details] selinux disabled
Dan - I think I've captured the AVCs correctly. Is polkit-read-auth the culprit this time?
Closing all bugs that have been in modified for over a month. Please reopen if the bug is not actually fixed.
This bug is not fixed. I have just verified that with kernel 2.6.27.5-41 and selinux-policy-targeted 3.3.1-107.
Can you attach the latest avc messages that you are seeing.
Created attachment 325257 [details] audit.log Here you go - audit.log from when I ran semodule -DB to after my login attempts.
Still broken with selinux-policy-targeted-3.3.1-115, ypbind-1.20.4-6.
getsebool -a | grep ypbind
(In reply to comment #48) > getsebool -a | grep ypbind allow_ypbind --> on See also comment #7 Also note that this is with F9 fully updated to current as of today.
What does # sesearch --allow -s system_chkpwd_t -t hi_reserved_port_t WARNING: This policy contained disabled aliases; they have been removed. Found 4 semantic av rules: allow system_chkpwd_t @ttr0172 : tcp_socket { recv_msg send_msg } ; allow system_chkpwd_t @ttr0172 : udp_socket { recv_msg send_msg } ; allow system_chkpwd_t @ttr1177 : tcp_socket name_bind ; allow system_chkpwd_t @ttr1177 : udp_socket name_bind ; Show (F10 output?)
Found 4 semantic av rules: allow system_chkpwd_t @ttr1084 : tcp_socket name_bind ; allow system_chkpwd_t @ttr1084 : udp_socket name_bind ; allow system_chkpwd_t @ttr0165 : tcp_socket { recv_msg send_msg }; allow system_chkpwd_t @ttr0165 : udp_socket { recv_msg send_msg };
Hey! It's working again! Not quite sure when; I had forgotten to mount my home directories earlier today, so that would have been the issue today. Not quite sure which policy update solved it though.