From: Russell Coker <russell@coker.com.au>
To: selinux@tycho.nsa.gov
Subject: ssh/cron access checks and my Play Machine
Date: Sat, 1 Apr 2017 23:59:15 +1100 [thread overview]
Message-ID: <201704012359.15451.russell@coker.com.au> (raw)
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/
next reply other threads:[~2017-04-01 12:59 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-01 12:59 Russell Coker [this message]
2017-04-01 14:25 ` ssh/cron access checks and my Play Machine Dominick Grift
2017-04-01 14:36 ` Russell Coker
2017-04-03 19:46 ` Stephen Smalley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201704012359.15451.russell@coker.com.au \
--to=russell@coker.com.au \
--cc=selinux@tycho.nsa.gov \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.