New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
adrelanos opened this Issue Aug 15, 2015 · 7 comments

Comments

Projects
None yet
3 participants
@adrelanos
Member

adrelanos commented Aug 15, 2015

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

This comment has been minimized.

Show comment
Hide comment
@nrgaway

nrgaway Aug 17, 2015

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?

nrgaway commented Aug 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@adrelanos

adrelanos Aug 17, 2015

Member

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

Member

adrelanos commented Aug 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Aug 26, 2015

Member

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?

Member

marmarek commented Aug 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@adrelanos

adrelanos Aug 26, 2015

Member

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?

Member

adrelanos commented Aug 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Aug 26, 2015

Member

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?

Member

marmarek commented Aug 26, 2015

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

This comment has been minimized.

Show comment
Hide comment
@adrelanos

adrelanos Aug 26, 2015

Member

Since,

  • my originally proposed (#1122 (comment)) solution using /etc/apparmor.d/tunables/home.d/qubes is only a workaround
  • and #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?

Member

adrelanos commented Aug 26, 2015

Since,

  • my originally proposed (#1122 (comment)) solution using /etc/apparmor.d/tunables/home.d/qubes is only a workaround
  • and #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 marmarek added this to the Release 3.1 milestone Sep 2, 2015

@marmarek marmarek removed this from the Release 3.1 milestone Sep 2, 2015

@marmarek

This comment has been minimized.

Show comment
Hide comment
@marmarek

marmarek Sep 2, 2015

Member

Good idea, one ticket less :)

Member

marmarek commented Sep 2, 2015

Good idea, one ticket less :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment