[SOLVED] SELinux blocking sshd access to shadow

[blueflame]

I'm trying to setup ssh access on my Fedora 12 laptop. I get the following error message in /var/log/secure when I try to login from another machine using ssh and the login is denied:

sshd[3025]: error: Could not get shadow information for <user>
sshd[3025]: Failed password for <user> from <ip> port <port> ssh2

If I do a 'setenforce 0' I can login and no error is logged.

Does anyone know what SELinux setting is causing this and how to fix it?

[Nokia]

Post

rpm -q selinux-policy{,-targeted}

[domg472]

Can you please enclose AVC denials. AVC denials have all the information we need to make proper security decisions.

[blueflame]

Originally Posted by domg472

Can you please enclose AVC denials. AVC denials have all the information we need to make proper security decisions.

Forgive my ignorance but what are AVC denials and how would I know they have occurred? Are they logged somewhere?

How will this help me?

rpm -q selinux-policy{,-targeted}

[domg472]

Please run the following chain of commands and enclose its output here:

ausearch -m avc -ts yesterday | grep shadow_t

AVC denials are usually stored in /var/log/audit/audit.log

AVC denials (Access vector cache denials) are log messages of Access vectors that (in this case) have been denied by SELinux.

You can install setroubeshoot if you wish to be notified (on the desktop or in /var/log/messages) when such AVC denials happen. setroubleshoot basically relays AVC denials to desktop sessions or to /var/log/messages (i do not encourage the use of setroubleshoot though).

The output of command "rpm -qa | grep selinux-policy" will help us determine which version of policy you are using.

[blueflame]

I have setroubleshoot installed but it didn't give me any alerts at the time.

# rpm -q selinux-policy{,-targeted}
selinux-policy-3.6.32-92.fc12.noarch
selinux-policy-targeted-3.6.32-92.fc12.noarch

# ausearch -m avc -ts yesterday | grep shadow_t
<no matches>

This appears in /var/log/audit/audit.log when the ssh login fails:

type=USER_LOGIN msg=audit(1267880088.534:20): user pid=2906 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='acct="awalker": exe="/usr/sbin/sshd" hostname=? addr=192.168.1.1 terminal=sshd res=failed'

There's nothing about ssh in /var/log/messages.

[jpollard]

It almost sounds like the shadow file has the wrong mandatory access control label.

Do a "ls -lZ /etc/shadow".. It should look like:

$ ls -lZ /etc/shadow
-r--------. root root system_u:object_r:shadow_t:s0 /etc/shadow

If this is not what you have, you can try "restorecon -f /etc/shadow", just "restorecon" (which will restore labels for
any file deemed incorrect).

This usually happens if you edit the file manually...

[domg472]

Thanks.

You have not been notified by setroubleshoot because no (visible) AVC denial occurred. The fact that command chain "ausearch -m avc -ts yesterday | grep shadow_t" returned "<no matches>" seems to acknowledge that.

There is a rule in SELinux that say's "if sshd tries to access /etc/shadow"; then silently deny it." This means that access is denied but the AVC denial is not actually logged.

The conclusion of this is that sshd_t should (in Fedora's opinion) not need to access /etc/shadow, and that attempts should be silently denied.

The fact that sshd seems to require access to /etc/shadow suggests that:

- either you have some exotic configuration of sshd
- either you have misconfigured sshd
- or this signals an intrussion
- or there is a bug in either sshd or selinux policy.

If you are positive that this access should be required (if you are sure that you have configured sshd correct), you may want to consider reporting this issue to bugzilla.redhat.com in the selinux-policy component.

[blueflame]

Looks ok ...

# ls -lZ /etc/shadow
-r--------. root root system_u:object_r:shadow_t:s0    /etc/shadow

---------- Post added at 09:28 PM CST ---------- Previous post was at 09:20 PM CST ----------

Originally Posted by domg472

Thanks.

You have not been notified by setroubleshoot because no (visible) AVC denial occurred. The fact that command chain "ausearch -m avc -ts yesterday | grep shadow_t" returned "<no matches>" seems to acknowledge that.

There is a rule in SELinux that say's "if sshd tries to access /etc/shadow"; then silently deny it." This means that access is denied but the AVC denial is not actually logged.

The conclusion of this is that sshd_t should (in Fedora's opinion) not need to access /etc/shadow, and that attempts should be silently denied.

The fact that sshd seems to require access to /etc/shadow suggests that:

- either you have some exotic configuration of sshd
- either you have misconfigured sshd
- or this signals an intrussion
- or there is a bug in either sshd or selinux policy.

If you are positive that this access should be required (if you are sure that you have configured sshd correct), you may want to consider reporting this issue to bugzilla.redhat.com in the selinux-policy component.

It's possible I have misconfigured sshd. However I am simply allowing password authentication and not trying anything with hosts-based or key-based authentication nor anything else fancy. If anyone wants to take a look at my sshd_config I'd be happy to post it.

I'm not about to file bugs ... sorry, too much hassle and time required for me.

For the moment the lesson seems to be set SELinux to Permissive and be shot of it!
Which is kind of disappointing ... but it's just given me too many headaches to be worth the effort for my situation.

[Nokia]

Try

su -
rm -fvr /etc/ssh/
yum reinstall openssh-server

[blueflame]

Originally Posted by Nokia

Try

su -
rm -fvr /etc/ssh/
yum reinstall openssh-server

Ok, problem solved

I don't know why, but hey I don't really care at this point.

Thanks, I should've tried that earlier!