[apparmor] AppArmor profile name and hard link question

[Seth Arnold]

On Wed, Sep 17, 2014 at 12:28:34AM +0000, Li, Li wrote:
> Hello,

Hello Lee,

> I am new to AppArmor. I am trying to port it to an embedded linux
> platform. One problem I found is related to file system and/or hard link
> issue.

Welcome aboard!

> The platform I have mount system files under /rom using squashfs first.
> Then mount another file system jffs2 as / and create hard links to all
> the files under /rom. So it looks to the system everything is under "/".
> The problem is when I create a profile with '/path/tofile' as name, it
> cannot be constrained even it detects there's a profile for it.  If I
> create a profile with '/rom/path/tofile', it can detect it only when I
> run the file using '/rom/path/tofile', not from the hard link
> '/path/tofile'.

I'm not familiar with squashfs or jffs2 -- do they really allow hardlinks
to cross filesystem boundaries? It was my understanding that hardlinks are
constrained to live 'within' a single filesystem -- which is one reason
why symbolic links were introduced.

Can you prepare a quick reproducer shell script which can be run easily on
e.g. a desktop system for testing? I'm curious what exactly has been done.

> I understand there's some issues with links for apparmor to work
> correctly, but is it already fixed? BTW, the kernel I have is 3.4 and I
> also applied the 3.4 apparmor patches.

You'll have to be more specific. Here's some points that often help people
new to AppArmor understand how it works behind the scenes:

AppArmor (well, the kernel) resolves symbolic links to a 'real' filename
before mediation. Permissions aren't checked on symlinks.

A confined progam may get different allowed permissions on a file
depending upon which hard link it uses to open the file: a file with
multiple hardlinks could have different permissions for different names.

A confined program that creates hardlinks to files needs to have
corresponding permissions to do so, and cannot expand its permissions
with this mechanism.

A program with multiple hardlinks use the specific hardlink in question
when determining attachment. For example, I always have a /tmp/bash
profile loaded that allows some very small things necessary for bash to
run, but nothing else. (It's great for testing.) But a /tmp/sh hardlink to
/tmp/bash doesn't run confined because the profile is for /tmp/bash.

You can run this kind of testing like this:

cat >/etc/apparmor.d/tmp.bash <<EOF
#include <tunables/global>
/tmp/bash {
  #include <abstractions/base>
  /tmp/bash rm,
}
EOF
apparmor_parser --replace /etc/apparmor.d/tmp.bash
cp /bin/bash /tmp/bash
ln /tmp/bash /tmp/sh
/tmp/bash  # notice this is confined, error messages etc ^D
/tmp/sh    # notice this is unconfined, no error messages ^D


I hope these cover your questions, but if you can prepare a quick shell
script to demonstrate what you mean, that'll make sure we're not talking
at cross-purposes to each other.

Thanks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20140917/62100579/attachment.pgp>