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 -- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
