[apparmor] sshd and profile transitions

[John Johansen]

On 09/29/2015 02:25 PM, Simon Deziel wrote:
> Hi everyone,
> 
> My sshd is contained by the attached profile (also available here [1]).
> Once logged in via SSH, I have an unconfined shell, at least according
> to "ps Zaux | grep $$". As such, I would expect to be able to run
> everything as usual but if I run a binary contained by Apparmor (like
> tcpdump) I get the following denials:
> 
> apparmor="DENIED" operation="file_inherit" profile="/usr/sbin/tcpdump"
> name="/dev/pts/0" pid=1529 comm="tcpdump" requested_mask="wr"
> denied_mask="wr" fsuid=0 ouid=0
> [...]
> apparmor="DENIED" operation="getattr" info="Failed name lookup -
> disconnected path" error=-13 profile="/usr/sbin/tcpdump"
> name="apparmor/.null" pid=1529 comm="tcpdump" requested_mask="r"
> denied_mask="r" fsuid=0 ouid=0
> 
Okay, so apparmor is checking all the open file descriptors that tcpdump
is inheriting. Ones that are not allowed are being "closed" during the
file inherit pass. I say "closed" because we don't actually close the
file, the associated file descriptor may have significance to the
application, eg fd 1 is stdout, etc. It is entirely possible the parent
is passing an open file, and the fd # by args or environment etc. Truly
closing the fd would make it available for reuse and that could cause
strange failures.

So instead of actually closing the file, apparmor redirects its to be a
file to a special null device that apparmor sets up. In most cases
(reads and writes) will not result in further logging, but some cases
like getattr will result in logging extra denials about access to
"apparmor/.null". This is just an artifact of how the lsm is setup, and
how apparmor is handling things internally atm. Ideally we will get
around to fixing these cases to not log as well, but we have a lot of
higher priority items to tackle first.

> Adding "/dev/pts/[0-9]* rw" to the tcpdump profile fixes the problem but
> it seems like the wrong way. FYI, this also happens with other programs
> confined by AA.
> 
yeah I agree that it is the wrong way, but unfortunately atm it is what
needs to be done. Really the parent should be delegating access of the
pts fd to its child. However this ability has not landed yet. It will
come, without apparmor is stuck doing an ambient authority which is not
what we want.

> I tried putting the sshd profile in complain mode to see if I was
> missing something but it doesn't help nor log anything additional.
> 
yeah I expect there is nothing else especially if adding the /dev/pts/...
rule made it go away.

> My last attempt was to give sshd access to all the existing capabilities
> but it didn't help. I tried that because I noticed that sys_ptrace could
> be missing from a profile without any denial being logged.
> 
Hrmm interesting that if sys_ptrace is missing no denial is logged. I'm not
sure what is going on there. Will have to dig to say anything more

> Any hints on what's going on here would be greatly appreciated.
> 
hopefully the above explanation fills in the gaps, if not let me know