Bug 450027 - selinux blocks NIS
selinux blocks NIS
Product: Fedora
Classification: Fedora
Component: selinux-policy (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Miroslav Grepl
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-06-04 16:19 EDT by Peter Dawes
Modified: 2009-03-12 07:52 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-03-12 07:52:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
audit.log (15.04 KB, text/plain)
2008-06-04 16:19 EDT, Peter Dawes
no flags Details
audit.log enforcing (4.70 KB, application/octet-stream)
2008-06-05 17:54 EDT, Peter Dawes
no flags Details
audit.log permissive (6.72 KB, application/octet-stream)
2008-06-05 17:55 EDT, Peter Dawes
no flags Details
results of audit2why (1.19 MB, text/plain)
2008-06-10 16:49 EDT, Peter Dawes
no flags Details
audit2allow log (1.87 KB, text/plain)
2008-06-16 10:00 EDT, Peter Dawes
no flags Details
audit.log (13.16 KB, application/octet-stream)
2008-07-02 15:13 EDT, Peter Dawes
no flags Details
audit.log with SELinux enabled (696.65 KB, application/octet-stream)
2008-07-29 16:53 EDT, Peter Dawes
no flags Details
selinux disabled (2.02 MB, application/octet-stream)
2008-07-29 16:53 EDT, Peter Dawes
no flags Details
audit.log (1.42 MB, text/plain)
2008-12-01 11:53 EST, Peter Dawes
no flags Details

  None (edit)
Description Peter Dawes 2008-06-04 16:19:11 EDT
Description of problem:
NIS provided users can't login to selinux enabled system

Version-Release number of selected component (if applicable):

How reproducible:

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.
Comment 1 Peter Dawes 2008-06-04 16:19:11 EDT
Created attachment 308394 [details]
Comment 2 Daniel Walsh 2008-06-05 15:53:47 EDT
With 3.3.1-62 installed pleas update the AVC's that you are seeing.
Comment 3 Peter Dawes 2008-06-05 17:54:51 EDT
Created attachment 308492 [details]
audit.log enforcing

This is the audit log with selinux-policy 3.3.1-62, with selinux set to
Comment 4 Peter Dawes 2008-06-05 17:55:40 EDT
Created attachment 308493 [details]
audit.log permissive

This is the audit.log with selinux-policy 3.3.1-62, set to permissive.
Comment 5 Peter Dawes 2008-06-05 17:58:38 EDT
Both of the above log file extracts were collected after having run semodule -DB
(otherwise much less info is recorded).
Comment 6 Daniel Walsh 2008-06-09 15:46:56 EDT
setsebool -P allow_ypbind=1

Should allow ypbind users to login.
Comment 7 Peter Dawes 2008-06-09 16:00:12 EDT
This is with allow_ypbind=1 set.  I have also tried setting to 0, relabeling,
then setting back to 1 and relabeling.
Comment 8 Daniel Walsh 2008-06-10 16:35:25 EDT
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 

Comment 9 Peter Dawes 2008-06-10 16:49:47 EDT
Created attachment 308867 [details]
results of audit2why
Comment 10 Peter Dawes 2008-06-10 16:51:56 EDT
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.

Comment 11 Peter Dawes 2008-06-13 09:47:12 EDT
I've just updated to the current Fedora 9 packages (kernel-,
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.
Comment 12 Daniel Walsh 2008-06-16 06:24:27 EDT
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?
Comment 13 Peter Dawes 2008-06-16 10:00:35 EDT
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.
Comment 14 Daniel Walsh 2008-06-22 08:42:13 EDT
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.
Comment 15 Peter Dawes 2008-06-23 09:18:10 EDT
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.
Comment 16 Peter Dawes 2008-06-23 09:58:17 EDT
Oh well, that didn't help either.  Nor did re-labeling after having applied this
latest policy.  
Comment 17 Daniel Walsh 2008-06-24 06:12:53 EDT
Sorry 68 was broken,  Try 69 or 70
Comment 18 Peter Dawes 2008-06-24 14:31:49 EDT
Where do I get one of those versions?  They don't seem to be in the
updates-testing repo.
Comment 19 Daniel Walsh 2008-06-25 08:02:31 EDT
69 should be released.  70 is in koji.  I will building a new test release by
Comment 20 Peter Dawes 2008-06-25 09:48:07 EDT
OK, I've installed 69.  Unfortunately, it hasn't resolved the problem.  The
error messages remain the same.
Comment 21 Daniel Walsh 2008-06-29 08:19:29 EDT
Peter, just out of curiosity, ls -l /etc/selinux/targeted/policy
Comment 22 Peter Dawes 2008-06-30 00:51:50 EDT
ls -l /etc/selinux/targeted/policy/ gives:

total 2220
-rw-r--r-- 1 root root 2266448 2008-06-25 09:45 policy.23
Comment 23 Daniel Walsh 2008-07-02 12:05:54 EDT
You have got me stumped.

Steve do you have any ideas?
Comment 24 Stephen Smalley 2008-07-02 13:20:13 EDT
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

Comment 25 Peter Dawes 2008-07-02 15:10:06 EDT
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-, 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.  
Comment 26 Peter Dawes 2008-07-02 15:13:33 EDT
Created attachment 310842 [details]

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
Comment 27 Stephen Smalley 2008-07-02 15:23:45 EDT
Hmmm...I see a net_bind_service denial still.  Try appending the following to
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)

Then re-insert it:
semodule -i mymodule.pp
Comment 28 Peter Dawes 2008-07-02 15:34:58 EDT
[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
Comment 29 Stephen Smalley 2008-07-02 15:47:15 EDT
class capability { net_bind_service };
inside the require { } block in mymodule.te.

Comment 30 Peter Dawes 2008-07-02 16:12:05 EDT
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?
Comment 31 Stephen Smalley 2008-07-03 08:12:33 EDT
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.

Comment 32 Peter Dawes 2008-07-03 09:37:40 EDT
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.
Comment 33 Stephen Smalley 2008-07-03 09:45:35 EDT
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.
Comment 34 Daniel Walsh 2008-07-03 12:18:29 EDT
		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.
Comment 35 Daniel Walsh 2008-07-03 12:23:08 EDT
Fixed in selinux-policy-3.3.1-76
Comment 36 Stephen Smalley 2008-07-09 09:39:18 EDT
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.
Comment 37 Stephen Smalley 2008-07-09 09:59:44 EDT
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.
Comment 38 Peter Dawes 2008-07-25 17:00:01 EDT
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?

Comment 39 Daniel Walsh 2008-07-29 16:01:15 EDT
semodule -r mymodule

will remove the custom module.

Could you show me your latest avc messages with 79 installed.
Comment 40 Peter Dawes 2008-07-29 16:53:09 EDT
Created attachment 312933 [details]
audit.log with SELinux enabled
Comment 41 Peter Dawes 2008-07-29 16:53:33 EDT
Created attachment 312934 [details]
selinux disabled
Comment 42 Peter Dawes 2008-07-29 16:57:07 EDT
Dan - I think I've captured the AVCs correctly.  Is polkit-read-auth the culprit
this time?
Comment 43 Daniel Walsh 2008-11-17 17:04:26 EST
Closing all bugs that have been in modified for over a month.  Please reopen if the bug is not actually fixed.
Comment 44 Peter Dawes 2008-11-26 12:41:49 EST
This bug is not fixed.  I have just verified that with kernel and selinux-policy-targeted 3.3.1-107.
Comment 45 Miroslav Grepl 2008-12-01 11:06:44 EST
Can you attach the latest avc messages that you are seeing.
Comment 46 Peter Dawes 2008-12-01 11:53:10 EST
Created attachment 325257 [details]

Here you go - audit.log from when I ran semodule -DB to after my login attempts.
Comment 47 Peter Dawes 2008-12-12 15:00:53 EST
Still broken with selinux-policy-targeted-3.3.1-115, ypbind-1.20.4-6.
Comment 48 Daniel Walsh 2009-03-02 21:26:43 EST
getsebool -a | grep ypbind
Comment 49 Peter Dawes 2009-03-11 09:53:00 EDT
(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.
Comment 50 Daniel Walsh 2009-03-11 11:40:15 EDT
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?)
Comment 51 Peter Dawes 2009-03-11 12:30:42 EDT
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 };
Comment 52 Peter Dawes 2009-03-11 12:35:08 EDT
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.

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