Qubes /usr/local symlink /rw/usrlocal AppArmor issue

[adrelanos]

issue description:
I found a Qubes specific AppArmor issue.

Qubes symlinks /usr/local to /rw/usrlocal and AppArmor does not like this.

user@host:~$ obfsproxy -h
Traceback (most recent call last):
  File "/usr/bin/obfsproxy", line 5, in <module>
    from pkg_resources import load_entry_point
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2876, in <module>
    working_set = WorkingSet._build_master()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 440, in _build_master
    ws = cls()
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 433, in __init__
    self.add_entry(entry)
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 489, in add_entry
    for dist in find_distributions(entry, True):
  File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1902, in find_on_path
    for entry in os.listdir(path_item):
OSError: [Errno 13] Permission denied: '/rw/usrlocal/lib/python2.7/dist-packages'

audit: type=1400 audit(1439566453.497:15): apparmor="DENIED" operation="open" profile="/usr/bin/obfsproxy" name="/rw/usrlocal/lib/python2.7/dist-packages/" pid=4078 comm="obfsproxy" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

Upstream AppArmor won't add symlink support:
https://bugs.launchpad.net/apparmor/+bug/1485055

proposed solution:

I am suggesting to ship a file /etc/apparmor.d/tunables/home.d/qubes with the following content:

alias /usr/local -> /rw/usrlocal/,

Also some explanatory comment should be added. And perhaps this will needs to be extended over time with more entries. There is also a file /etc/apparmor.d/tunables/home.d/ubuntu already, so this seems appropriate. In which package? qubes-core-agent, I suppose?

If this solution sounds alright to you, I can send a pull request.

[nrgaway]

I assume you have tested this already. Just wanted to make sure that an alias will not effect the mounting of /rw/usrlocal to /usr/local?

[adrelanos]

Yes, this is tested and working.

Doesn't affect that. Affecting mount should be far outside of AppArmors's scope. (There is no AppArmor profile for mount, if that even would make sense.)

[marmarek]

I don't know AppArmor at all, but above (together with an idea about
qubes-core-agent) looks good.

BTW some applications had a problem with /home->/rw/home symlink, AFAIR
because realpath $HOME != $HOME. Because of that /home is now
bind-mounted from /rw/home. Do you think we should do the same with
/usr/local? This is the first issue ever caused by that /usr/local
symlink, so maybe not.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

Do you think we should do the same with /usr/local?

Yes. For better consistency.

---

I am not sure I yet have experienced /rw/home related AppArmor symlink issues, but all symlinks should have corresponding alias' configured. I'll include alias /home -> /rw/home/, in my pull request.

Are there any other (bind-) mounted locations or a list of those which probably also should be included?

[marmarek]

On Wed, Aug 26, 2015 at 09:10:39AM -0700, Patrick Schleizer wrote:

Do you think we should do the same with /usr/local?

Yes. For better consistency.

Ok. But since mounting /rw get more and more complex, I think we should
do this only after #979.

I am not sure I yet have experienced /rw/home related AppArmor symlink issues, but all symlinks should have corresponding alias' configured. I'll include alias /home -> /rw/home/, in my pull request.

I think this is unnecessary, as /home is bind-mounted now.

Are there any other (bind-) mounted locations or a list of those which probably also should be included?

Actually I think bind mounted locations shouldn't be a problem for
AppArmor. Symlinks are.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[adrelanos]

Since,

• my originally proposed (Qubes /usr/local symlink /rw/usrlocal AppArmor issue #1122 (comment)) solution using /etc/apparmor.d/tunables/home.d/qubes is only a workaround
• and Bind mount /rw/usrlocal -> /usr/local instead of symlink #1150 is the appropriate fix that you triaged for 3.1 [feels not so far],

what do you think about not implementing / closing this ticket?

[marmarek]

Good idea, one ticket less :)