On Sat, Apr 01, 2017 at 11:59:15PM +1100, Russell Coker wrote: > Ever since the earliest days of SE Linux (at least 2001 according to my > recollection) the cron patches for SE Linux have included a check of the > context of the crontab file to ensure that the policy specifies that it is > permitted to have crontab entries to run in the context in question. Such > checks were comparable to the checks in crond for a UID match for running the > job with Unix permissions, but a little more complex because we aren't just > dealing with UIDs. > > The sshd checks the Unix permissions of ~/.ssh/authorized_keys to ensure that > only the owner of the account in question and the primary group of that > account can write to it, ~/.ssh, and ~. But we don't have similar checks for > SE Linux permissions. I really should have thought of this back when I was > doing a lot of the maintenance for the SE Linux patches for cron and sshd. > > To test this, try "chmod 666 ~/.ssh/authorized_keys" and then observe that you > can't ssh to that account without a password. Then use chcon to set the type > of the authorized_keys file to something inappropriate but readable by sshd_t > (such as user_tmpfs_t or etc_t) or set the identity to something other than > system_u or the identity of the account in question and observe that you can > still login without a password. So youre saying the a policy upgrade changed the permissions of ~/.ssh/authorized_keys from 0600 to ???? how is that possible? Also is ~ not set to 0700? User wouldnt be able to traverse to other uids' ~/.ssh > > During a recent upgrade to my SE Linux Play Machine (or to be more specific the > Debian/Unstable Play Machine that recently replaced the Debian/Jessie > instance) the permissions were reset on the home directory of the sysadm_r > account by a policy upgrade and I didn't notice and set them correctly. This > made it theoretically possible for a user_r user to modify the authorized_keys > file, login to the sysadm_r account, and then totally pwn the system. How do you figure that? you are not specific about what permissions were reset to what exactly Anyhow, It wouldnt be be first time that your play-machine was compromised if i recollect correctly. So i do not doubt that its possibly compromized but I do not see how a policy update would change permission bits of ~/.ssh/authorized_keys from 0600 to something world writable and how other uids would be able to traverse sysadms' homedir if thats set to 0700 as well. > > Today I noticed that sshd was taking more memory than usual and user_r logins > were failing with the error "fatal: monitor_apply_keystate: packet_set_state: > memory allocation failed". Only user_r logins were failing because only > user_r has a memory limit set in /etc/security/limits.conf. This raises the > possibility that someone replaced sshd or a library it depends on. I'll make > the system image available to anyone who wants to do forensics. I am not > certain that the system was compromised at this stage. But given that it > could have been compromised and that it was operating in a different way to > what I expected I think it's most reasonable to assume that it was. > > Some people may wonder why I am posting this on the first of April. Someone > sent an April 1st joke to a mailing list that had obfuscinated shell code and > my usual practice is to login to my Play Machine as user_r to run suspect > code. This is what led me to discover the problem. That said, there is > evidence that the system might have been running correctly yesterday. > > When running such systems there have been a number of incidents of problems > discovered. As long as the end result is improvement of knowledge about > computer security (both by the person running the system and the community) or > an improvement in SE Linux to make such attacks more difficult in future (which > I aim to implement by changes to policy and PAM/sshd code) it can be counted > as a win for us. I think that this will end up achieving the aims of > education and software improvement. So while it sucks a bit, the end result > should be positive. > > -- > My Main Blog http://etbe.coker.com.au/ > My Documents Blog http://doc.coker.com.au/ > _______________________________________________ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to Selinux-leave@tycho.nsa.gov. > To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02 Dominick Grift