OpenRC's start-stop-daemon will by default run an "un-user-ed" daemon as nobody (uid=65534). The SSH dameon then reports to proc a loginuid as 65534. SELinux (used by the Hardened Gentoo) requires the the of audit, which then reports through libaudit's audit_getloginuid() that uid. SELinux's newrole then uses that uid to spawn a shell, which is normally set to /bin/false (not in the /etc/shells file) and as such reports an error. Reproducible: Always Steps to Reproduce: 1. Use OpenRC 0.9.x on Gentoo Hardened machine to spawn SSHD 2. Login through SSH account that is a staff_u user 3. Try to newrole -r sysadm_r Actual Results: Error! Shell is not valid. Expected Results: The account password should be prompted for The suggested fix should be that SSHD run as a user that can setuid spawned programs with a valid shell (requiring a modification to the start-stop-daemon options in init.d). As a temporary fix roll back to OpenRC 0.8.3-r1
That doesn't seem to be a OpenRC issue.
looks to me like the openrc s-s-d has always worked this way when built with USE=pam: it calls pam_start() with "nobody". so i don't see why downgrading to an older version of openrc would make any difference at all. however, that is not the UID that sshd is run as. it always runs as root because the initial init.d script is run as root. then when sshd starts a pam session, it does so as the user that it is logging in. someone on the selinux side will have to poke to see what's actually going on.
(In reply to comment #2) > looks to me like the openrc s-s-d has always worked this way when built with > USE=pam: it calls pam_start() with "nobody". so i don't see why downgrading to > an older version of openrc would make any difference at all. > We tweaked the PAM rules recently to apply limits to the services.
I thought it odd as well, as one would expect sshd to be -1 (4294967295) the same as init (unless one restarts it and then it's that user account id). However when Hardened bumped to openrc-0.9.4 this changed to nobody (which doesn't cause login problems, only when one attempts to newrole). I'm currently running SSH with "UsePAM no" (to disallow root logins), so unless there is interaction during start-stop-daemon/system-services that has changed...
That's weird, the web site though I had a comment collision and asked to resend (so ignore comment 5 as it's a repeat).
Hi Paul, I'm not able to reproduce this. I have OpenRC 0.9.x on a Gentoo Hardened system (pax/grsec/selinux) running strict policy, enforcing, with USE="ubac" set. Do you get any errors or denials in the logs?
I was not able to reproduce the issue on any of my boxes at home. I log in as root. uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) context=root:staff_r:staff_t then switch to sysadm_t loki ~ # newrole -r sysadm_r uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video) context=root:sysadm_r:sysadm_t Do you get this issue with use_pam=yes? also, does anything show up in /var/log/audit/audit.log
The affected machines are servers so I have them locked down a little (hence the use of Hardened). I'm not using ubac (although that probably would be ok), and SSH does not use PAM so as to limit root login directly (one must first login as oneself to establish credentials via Kerberos, then newrole, and finally su). So yes I do see successful logins, and newrole transition errors. What seemed (to my limited knowledge by going through the source) was that SSHD was now running as 65534 (aka. nobody) that newrole attempts to use as the effective uid for the shell choice (which is /bin/false on my machine), see policycoreutils-2.1.0-r1 newrole.c extract_pw_data() when using audit. This not being on the list of shell choices in /etc/shells it returns a "Shell is not valid" error. Given that SSHD must change uid to that of the logging in user, I'm not sure that nobody is a valid account to run as to then spawn to subsequent daemons dedicated to that user. I can definitely see why one would not wish to run most daemons as such, much less their ability to spawn shells and change uid. Former versions of OpenRC seemed to run as -1 (4294967295 anyway) which then acts as root and thus spawns a valid shell as the user, and hence the rolling back in spite of the obvious advantages of new versions. What I'm also really not sure about though is newrole using audit_getloginuid() getting the effective uid (as opposed to the normal getuid() ) to choose the shell. On the surface it seems like a good idea... Oh and I did try this without Kerberos using PKI certs (same result of course), so reproducibility is not affected by the lack of GSSAPI.
(In reply to comment #9) > What seemed (to my limited knowledge by going through the source) was that SSHD > was now running as 65534 (aka. nobody) that newrole attempts to use as the > effective uid for the shell choice (which is /bin/false on my machine), see > policycoreutils-2.1.0-r1 newrole.c extract_pw_data() when using audit. This not > being on the list of shell choices in /etc/shells it returns a "Shell is not > valid" error. I'm stuck at the start of that. How is SSHd running as "nobody" on your system? Here, it is running as root. swift@hpl policycoreutils $ ps -efZ | grep sshd system_u:system_r:sshd_t root 2553 1 0 20:12 ? 00:00:00 /usr/sbin/sshd
The start-stop-daemeon in the version of OpenRC (0.9.4) that I was running would use "nobody" unless changeuser is explicitly given (see about line 1183). Since the /etc/init.d/sshd does not specify a --user option, the dameon is run with a pid of 65534 (aka nobody). Witness by 'cat /proc/<pid of ssh>/loginuid' which is what libaudit's audit_getloginuid() reads (and therefore newrole uses). I would expect that the user should be root (of which if you 'ps' it is ... but the euid is not), hence this whole bit of fun! If there is a way to 'UsePAM yes' which will deny direct root login in the same was that 'PermitRootLogin no' does, I'll give that a go.
openrc's ssd creates a pam context based on the nobody user. but it isn't changing id to that user. certainly on my system, sshd isn't dropping root, and the man pages for pam_{start,acct_mgmt,open_session} don't say that calling these functions will change the uid/gid. and if they did, the latter code in ssd wouldn't make any sense where it explicitly changes uid/gid to the user specified via the --user flag. maybe you have a non-standard pam module in your stack that is screwing things up. hopefully the pam team can provide debugging insight.
Interesting and makes sense, as I could not see how SSHD could setuid without being root. Why then is the loginuid nobody (which is sort of the issue for newrole)? $ ps -efZ | grep sshd system_u:system_r:sshd_t root 1766 1 0 08:41 ? 00:00:00 /usr/sbin/sshd system_u:system_r:sshd_t root 1825 1766 0 08:41 ? 00:00:00 sshd: pdd [priv] system_u:system_r:sshd_t pdd 1827 1825 0 08:41 ? 00:00:00 sshd: pdd@pts/0 $ cat /proc/1766/loginuid 65534 $ cat /proc/1825/loginuid 65534 $ cat /proc/1827/loginuid 65534 $ newrole -r sysadm_r Error! Shell is not valid. Note: this is after re-emergeing pam-1.1.5 and openrc-0.9.4, just to make sure that there is nothing non-standard using the stock pam settings. I'm not sure either: the start-stop-daemon / the SSHD init.d script / the newrole use of audit's uid are incorrect or don't work (as console login / newrole still works fine); just that their combination seems to produce an untenable position.
Here, loginuid is 65534 too: swift@hpl ~ $ ps -ef | grep sshd root 2589 1 0 19:22 ? 00:00:00 /usr/sbin/sshd swift@hpl ~ $ cat /proc/2589/loginuid 65534 swift@hpl ~ $ getent passwd 65534 nobody:x:65534:65534:nobody:/:/bin/false Yet newrole just works as expected (apart from bug #375475).
Are you compiling with audit? If not the code would seem to use the standard getuid() approx. line 425 (which would then return root, instead of nobody). Your nobody account is identical to mine, so I don't see how you too would either end up not receiving the shell error (or even trying to execute false, which wouldn't get that far either :} ).
I have no option to compile with or without audit: [I] net-misc/openssh Available versions: 5.5_p1-r2 5.6_p1-r2 ~5.7_p1-r1 5.8_p1-r1 ~5.8_p2 ~5.8_p2-r1 ~5.9_p1-r3 {X X509 (+)hpn kerberos ldap libedit pam selinux skey static tcpd} Installed versions: 5.8_p1-r1(22:03:59 02/13/11)(X hpn pam selinux tcpd -X509 -kerberos -ldap -libedit -skey -static) Homepage: http://www.openssh.org/ Description: Port of OpenBSD's free SSH release
I'm sorry I should have been more specific. In policycoreutils (v2.1.0-r1) under the newrole subdirectory in the newrole.c file starting at line 425 is a compile option to use libaudit's getloginuid (or getuid). This is then used to get the shell that should be changed to when newrole is executed. The use of the audit option is through the existence of the libaudit header file (from audit-1.7.4). If one logs in from the console the loginuid of the process is 4294967295 (effectively -1) which equates to root and the shell is that user (in my case root:x:0:0:root:/root:/bin/bash). If one instead logs in via ssh the loginuid of the process is 65534 which equates to nobody and the shell is (in my case nobody:x:65534:65534:nobody:/:/bin/false) which is not in the list of acceptable shells of the /etc/shells file. Thus returning the "Error! Shell is not valid." message. So, to my limited knowledge of the system there are three options for fixes: First, roll back OpenRC versions: the SSHD is run as a loginuid of root, a quick but not very good long term solution; Second, run SSHD as a privileged user: this remediates the loginuid issue as well, but is also probably not a good idea from a security stance; or Third, remove the use of libaudit from newrole (by editing the Makefile): I'm not sure about the long term ramifications of this option, as I'm not quite sure why it's inclusion was in the first place (vs. the traditional getuid). To find closure I suppose I should contact the authors at redhat. Perhaps there is a better solution which I hope that you might suggest.
policycoreutils here is installed while libaudit's header files are present and my build logs confirm that -DUSE_AUDIT is used. Although sshd (the parent one) runs with loginuid 65534, its child (the one spawned the moment you log on) has loginuid of the user (in my case, 1001). I think the issue here is that you have "UsePAM no". As a result, SSHd does not set the loginuid. Perhaps if you set "UseLogin yes" this will help?
I suspect that you are correct, however I am hesitant to implement this solution as it would open up known vulnerabilities (in command execution US-CERT#40327) within SSHD. Removing the use of libaudit from newrole fixes the problem as the uid (but not the effective uid aka. loginuid) is set correctly by SSHD. Honestly in looking through the libaudit code, I still do not understand its inclusion over the traditional getuid() as alternatives for recording exist. The fourth option could be modifications to PAM system-remote-login so as to disallow direct root access using some form of pam_rootok or 'auth required pam_succeed_if.so user != root quiet' (as using DenyUser root / DenyGroups root in sshd_config is apparently insufficient). Unfortunately I am not an expert in the ways of PAM, so would be interested if you have opinions on the matter (particularly when using Kerberos in conjunction with SSH).
I'm going to create optional audit support for the policycoreutils package and see how it behaves with both USE="audit" and USE="-audit" on some test cases. If there are no specific issues here, I'll add that in so you can at least go forward. To disallow direct root login, why not just set PermitRootLogin no?
policycoreutils-2.1.0-r2 is now in the hardened-dev overlay. It uses IUSE="pam audit". For you, that should allow you to build it without audit (and hence support the configuration). Most of my test systems also don't have USE="audit" set so it's not that uncommon ;-) For some stupid reason, the application itself scanned the system to see if it wanted to include audit support or not - not according to Gentoo's rules (these are things we always want to do with USE flags).
That's great, I'll give it a go. I do use SSHD with PermitRootLogin set to no, but in the past also requires UsePAM set to no (I should re-review this requirement in the code / settings).
The newrole command seems to work the same as my kludged one, and your additions to the policycoreutils ebuild seems like a good thing in general. I'll try to beat on it over the next couple of days, but so far it's a thumbs up! Thanks for your persistence on this (I know many who would have thrown up their hands and said it's your problem)!
Thanks, good to hear. I also didn't hear any problems with these latest changes so I'll push them to the tree in the next batch. And it's I that needs to thank you for being persistent, I know many who wouldn't even look at their bugs after all this questioning ;-)
Pushed to main tree, ~arch
Stabilized
