ssh/cron access checks and my Play Machine

ssh/cron access checks and my Play Machine

[Russell Coker]

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.

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.

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/

Re: ssh/cron access checks and my Play Machine

[Dominick Grift]

[-- Attachment #1: Type: text/plain, Size: 4794 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: ssh/cron access checks and my Play Machine

[Russell Coker]

On Sun, 2 Apr 2017 01:25:41 AM Dominick Grift wrote:
> So youre saying the a policy upgrade changed the permissions of
> ~/.ssh/authorized_keys from 0600 to ???? how is that possible? Also is ~

No, a policy upgrade and relabel.

> not set to 0700? User wouldnt be able to traverse to other uids' ~/.ssh

Unless they have the same UID, which is the point of a Play Machine.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

Re: ssh/cron access checks and my Play Machine

[Stephen Smalley]

On Sat, 2017-04-01 at 23:59 +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.
> 
> 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.
> 
> 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.

I'm not clear that it is justified or desirable to modify sshd in this
manner.  The case of cron seems fundamentally different; effectively we
had crond emulate the entrypoint check that would have occurred if
crontab files were directly executed, between the context of the cron
job process and crontab file, since a crontab file is in a sense a
script and we perform a domain transition there.  This differs from
sshd using input from authorized_keys, which is already governed by a
MAC check on reading from the file (arguably your policy shouldn't
allow sshd to read other user home types).  sshd checking of DAC file
modes for authorized keys is understandable, given that DAC modes are
subject to user carelessness and to flawed or malicious applications
run by the user.  In contrast, MAC labels can only be changed in
accordance with the policy, which is administratively defined in the
first place; if you can change the label on the file, then chances are
you could do worse things.  And what would sshd check the file label
against?  file_contexts?  If so, then that wouldn't help with your
upgrade scenario.  We certainly don't want to hardcode a context in
sshd or create yet another contexts configuration file to manage.  We
could perform a userspace permission check, but would need to invent a
new class/permission for that purpose (allow sshd_t ssh_home_t:ssh
authorized_keys;), and again that would end up being defined in policy,
so a policy upgrade could just as easily undo it.