[apparmor] sshd and profile transitions

[Simon Deziel]

On 09/29/2015 05:56 PM, John Johansen wrote:
> 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.

Interesting. Just to make it clear, I not only get logs but actual
denials as I cannot see any output from the packet captures. Saving the
trace to a file (-w) or using a shell redirection works though.

The inheritance thing is still a bit unclear to me. The AA contained
sshd process launches an uncontained bash process for my session so why
is AA still looking around for what's happening in that uncontained bash?

> 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.

Understood.

>> 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.

Is it this ambient authority behavior that explains why AA still
mediates the uncontained bash process and thus prevents a clean
transition to tcpdump in that chain:

sshd (contained) -> bash (uncontained) -> tcpdump (contained)


>> 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

I'm not sure what goes on but I know special conditions need to be meet
to reproduce.

So when /proc is mounted with hidepid>=1 and sshd isn't allowed to
sys_ptrace, pam_limits is unable to access /proc/1/limits to obtain the
default RLIMITs so it logs this:

sshd[2203]: pam_unix(sshd:session): session opened for user simon by (uid=0)
sshd[2203]: pam_limits(sshd:session): Could not read /proc/1/limits (No
such file or directory), using PAM defaults
sshd[2203]: pam_limits(sshd:session): Did not find kernel RLIMIT for
cpu, using PAM default
[...]


While it certainly qualifies as an edge case, an AA log would have been
helpful :)

>> 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

It helps that's for sure.

Thank you very much!

Simon

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20150930/f1b045df/attachment.pgp>