execution via bang-line not mediated by apparmor

Bug #1346553 reported by Andrew Lewis on 2014-07-21
256
This bug affects 1 person
Affects Status Importance Assigned to Milestone
AppArmor
Wishlist
Unassigned

Bug Description

Demonstration of problem:

testuser@bizarro:~$ /usr/bin/perl
-testbash: /usr/bin/perl: Permission denied
testuser@bizarro:~$ echo '#!/usr/bin/perl' > hello.pl
testuser@bizarro:~$ echo 'print "hello\n"' >> hello.pl
testuser@bizarro:~$ chmod a+x hello.pl
testuser@bizarro:~$ ./hello.pl
hello
testuser@bizarro:~$

Policy used in demonstration:

# Last Modified: Sat Jul 19 18:48:21 2014
#include <tunables/global>

/usr/local/bin/testbash {
  #include <abstractions/base>

  owner /home/*/** rwkix,
  /bin/cat rix,
  /bin/chmod rix,
  /usr/local/bin/testbash mr,

  /dev/tty rw,
  /dev/pts/* rw,
  /etc/bash.bashrc r,
  /etc/inputrc r,
  /etc/nsswitch.conf r,
  /etc/passwd r,
  /etc/profile r,
  /etc/profile.d/ r,
  /etc/profile.d/** r,
  /etc/vim/** r,
  /usr/share/vim/** r,
  /run/nscd/socket rw,
  /var/cache/nscd/group r,
  /var/cache/nscd/passwd r,
}

Seth Arnold (seth-arnold) wrote :

Okay, I've got a minimal test for this that doesn't rely upon anything outside of these files.

cp ~/Downloads/confined_interpreter.c /tmp
cd /tmp
make confined_interpreter
sudo -s
apparmor_parser --replace <<EOF
profile /tmp/confined_interpreter {
  /etc/ld.so.cache r,
  /lib/x86_64-linux-gnu/libc-2.19.so rm,
  /tmp/confined_interpreter ix,
  /tmp/runme.pl wix,
}
EOF
exit
/tmp/confined_interpreter

Even though /tmp/confined_interpreter is executing in a profile that doesn't include /usr/bin/perl in any way, the /usr/bin/perl executable is started, as evidenced by failure to load perl libraries:

/usr/bin/perl: error while loading shared libraries: libperl.so.5.18: cannot open shared object file: Permission denied

type=AVC msg=audit(1405991249.694:8453): apparmor="DENIED" operation="open" profile="/tmp/confined_interpreter" name="/usr/lib/libperl.so.5.18.2" pid=13472 comm="runme.pl" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Changed in apparmor:
status: New → Won't Fix
information type: Private Security → Public Security
Seth Arnold (seth-arnold) wrote :

This behaviour is expected; the 'executable' in this case is the shell script (/tmp/runme.pl in my example, ~/hello.pl in your example) -- and the interpreter is invoked almost as an aside.

We could investigate extending this as a feature request; I don't know if the design of binfmt_misc would make it 'easy' to add permission checks to the interpreter, but we wouldn't want to do it without some level of wider discussion first.

Thanks

John Johansen (jjohansen) wrote :

Alright I changed this to confirmed (it is a known behavior) and wishlist.

Yes this could be addressed in the kernel fairly easily. It does change existing known behavior, and discussion of whether this is a desired change is needed.

Note: it would now also be fairly trivial to make this abi dependent so that older policy would get the old behavior and new policy the new behavior if it was decided that this is a desired change.

Changed in apparmor:
importance: Undecided → Wishlist
status: Won't Fix → Confirmed
tags: added: aa-kernel
intrigeri (intrigeri) wrote :

One data point from myself (as a relatively experienced user of AppArmor, but no expert whatsoever): I was surprised to read this bug report, so to some degree this behaviour violates the principle of least surprise. Wishlist sounds fine, though.

To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers