Project

General

Profile

Feature #16423

Consider preventing changes to the AppArmor policy

Added by Anonymous 14 days ago. Updated 12 days ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
02/06/2019
Due date:
% Done:

0%

QA Check:
Info Needed
Feature Branch:
Type of work:
Sysadmin
Blueprint:
Starter:
Affected tool:

Description

Regarding : Using rules to avoid modifying profiles at https://tails.boum.org/contribute/design/application_isolation/

This feature is deprecated, however, a new one, available on tails but disabled just do this job

Enabling lock_policy of apparmor protect edit, disable, remove any profile, apparmor cannot be disabled too, the only to reverse this is a reboot.

To enable it, echo "Y" > /sys/module/apparmor/parameters/lock_policy

I tried on apparmor and it work as expected, adding it is simple and add some nice security that go beyond the root access. Next release of apparmor will bring a powerfull feature : https://gitlab.com/apparmor/apparmor/wikis/AppArmorSystemWideRestrictions

I checked the profiles rules, it's way to permissive, it can definitively be more strict without affecting usage of the appplications

Willing to give a hands

History

#1 Updated by Anonymous 14 days ago

s/the only to/the only way to/
s/I tried on apparmor/I tried on Tails/

(Dont known how to edit my post, sorry)

#2 Updated by intrigeri 14 days ago

  • Subject changed from Application isolation to Consider preventing changes to the AppArmor policy

#3 Updated by intrigeri 14 days ago

  • Assignee set to Anonymous
  • QA Check set to Info Needed

Hi gengreen!

First, I'm super happy someone is looking closely at our AppArmor policy and is interested in improving it. Woohoo!

Regarding : Using rules to avoid modifying profiles at https://tails.boum.org/contribute/design/application_isolation/
This feature is deprecated,

I think there's some confusion here. In that context, "to avoid modifying profiles" is about maintainability, i.e. avoid modifying profiles to work on our weird aufs+squashfs+tmpfs storage stack. It's not about locking down the policy.

however, a new one, available on tails but disabled just do this job
Enabling lock_policy of apparmor protect edit, disable, remove any profile, apparmor cannot be disabled too, the only to reverse this is a reboot.
To enable it, echo "Y" > /sys/module/apparmor/parameters/lock_policy
I tried on apparmor and it work as expected, adding it is simple and add some nice security that go beyond the root access.

Note that as a side effect, the simplest implementation of this (doing this early during boot) would:

  • Break installation of Additional Software that ship AppArmor policy: their postinst script will try to load the new profile and fail.
  • Prevent users from tweaking policy in /etc/apparmor.d/local/ via "dotfiles" persistence (not tested but I guess it currently works).

So this locking down would need to be applied only after persistence is set up and Additional Software are installed and upgraded.

Now, I wonder what's the thread model you're thinking of here. What's the advantage of preventing an adversary, who managed to get root credentials already, to modify the AppArmor policy? I mean, they can do basically anything already, so it feels like a lost cause to me. This could make sense if we were taking more steps to make root less powerful in Tails, but currently we don't. May you please elaborate?

Next release of apparmor will bring a powerfull feature : https://gitlab.com/apparmor/apparmor/wikis/AppArmorSystemWideRestrictions

Yeah, for some value of "next release". Let's discuss it once it's really a thing.

I checked the profiles rules, it's way to permissive, it can definitively be more strict without affecting usage of the appplications
Willing to give a hands

Excellent! As a rule we maintain our AppArmor policy upstream: sometimes directly in upstream software, sometimes within the AppArmor project, sometimes in Debian. It's not always obvious where that "upstream" lives but https://wiki.debian.org/AppArmor/Contribute/Upstream has a nice table that explains a little bit. I'll happily review your merge requests there :)

#4 Updated by Anonymous 14 days ago

intrigeri wrote:

Hi gengreen!

First, I'm super happy someone is looking closely at our AppArmor policy and is interested in improving it. Woohoo!

Regarding : Using rules to avoid modifying profiles at https://tails.boum.org/contribute/design/application_isolation/
This feature is deprecated,

I think there's some confusion here. In that context, "to avoid modifying profiles" is about maintainability, i.e. avoid modifying profiles to work on our weird aufs+squashfs+tmpfs storage stack. It's not about locking down the policy.

however, a new one, available on tails but disabled just do this job
Enabling lock_policy of apparmor protect edit, disable, remove any profile, apparmor cannot be disabled too, the only to reverse this is a reboot.
To enable it, echo "Y" > /sys/module/apparmor/parameters/lock_policy
I tried on apparmor and it work as expected, adding it is simple and add some nice security that go beyond the root access.

Note that as a side effect, the simplest implementation of this (doing this early during boot) would:

  • Break installation of Additional Software that ship AppArmor policy: their postinst script will try to load the new profile and fail.
  • Prevent users from tweaking policy in /etc/apparmor.d/local/ via "dotfiles" persistence (not tested but I guess it currently works).

So this locking down would need to be applied only after persistence is set up and Additional Software are installed and upgraded.

Now, I wonder what's the thread model you're thinking of here. What's the advantage of preventing an adversary, who managed to get root credentials already, to modify the AppArmor policy? I mean, they can do basically anything already, so it feels like a lost cause to me. This could make sense if we were taking more steps to make root less powerful in Tails, but currently we don't. May you please elaborate?

Next release of apparmor will bring a powerfull feature : https://gitlab.com/apparmor/apparmor/wikis/AppArmorSystemWideRestrictions

Yeah, for some value of "next release". Let's discuss it once it's really a thing.

I checked the profiles rules, it's way to permissive, it can definitively be more strict without affecting usage of the appplications
Willing to give a hands

Excellent! As a rule we maintain our AppArmor policy upstream: sometimes directly in upstream software, sometimes within the AppArmor project, sometimes in Debian. It's not always obvious where that "upstream" lives but https://wiki.debian.org/AppArmor/Contribute/Upstream has a nice table that explains a little bit. I'll happily review your merge requests there :)

Hey !

So I'm super exited about AppArmorSystemWideRestrictions,

Limit the permission/access to the system to someone who could gain the root by physical access of the machine or remote using vulnerability (let's say browser -> kernel flaw..)

In addition of the profiles apparmor, creating a profile global saying :

In any case, /etc/shadow should be edited
In any case, /bin:/usr/bin:/usr/local/bin are the only execution path allowed, no supplementary binary should be add, no binary should be edited
In any case. cannot add, link, preload any library
In any case, firewall rules (iptables), cannot be deleted, cannot add...
No change of ssh config, keys files allow host...
...
It's possible to restrict and rules what is allowed to be done in the whole system, even with the root compromised.

Adding a security model relaying on the kernel, beyond the root access as last defensive line, it's one more security layer and a good one.

About application isolation, indeed I mistaken. Regarding hardening the application profiles, it can be done as :

https://raw.githubusercontent.com/g3ngr33n/apparmor-profiles-hardened/master/apparmor.d/usr.lib.torbrowser.torbrowser
(just updated this one)

I don't have right in front of my eyes the apparmor profiles of Tails (will check later again) but could torbrowser don't allow at all any of /proc, /tmp, /sys... access, datareporting/ safebrowsing ? Removing any rules that are not needed

The firefox profiles of my git repo :

activity-stream.tippytop.json - Log your browsing history, even with "never remember history" or "private browsing" enabled.

If people rely on the apparmor shipped by the distro, it won't block this one

Maybe I'm too extreme, but it's hard to get some good security without grsecurity...

#5 Updated by Anonymous 14 days ago

Excellent! As a rule we maintain our AppArmor policy upstream: sometimes directly >in upstream software, sometimes within the AppArmor project, sometimes in Debian. >It's not always obvious where that "upstream" lives but https://wiki.debian.org
/AppArmor/Contribute/Upstream has a nice table that explains a little bit. I'll >happily review your merge requests there :)

I didn't read until the end, I just saw this part. Then compare the Firefox debian with on of my (It has comment), example allowing activity-stream.tippytop.json of Firefox, make private browsing, no log useless...

I made only few profiles but you will see the idea

#6 Updated by Anonymous 14 days ago

Alright I took 5 minutes :

https://pastebin.com/raw/wVi8vD1e

Profile of tbb in Tails, I restricted :

  1. Why ? # owner {PROC}/{pid}/environ r,
    #owner {PROC}/{pid}/fd/ r, # owner {PROC}/{pid}/mountinfo r, # owner {PROC}/{pid}/stat r, # owner {PROC}/{pid}/status r, # owner {PROC}/{pid}/task/*/stat r,
  2. @{PROC}/sys/kernel/random/uuid r,
    1. Why ?
      #/etc/machine-id r,
      #/var/lib/dbus/machine-id r,
    1. Why ?
      #/sys/devices/system/cpu/ r,
      #/sys/devices/system/cpu/present r,
      #/sys/devices/system/node/ r,
      #/sys/devices/system/node/node[0-9]*/meminfo r,

Apparmor restart, tbb work, I did not make an intensive but it work as expected.

This the kind of rules that need to be reviewed...

#7 Updated by intrigeri 12 days ago

Please:

  1. Answer the question I've asked, that will tell us what we should do with the problem this ticket is about (if anything).
  2. Keep this ticket well-scoped: I've retitled it so it's not about all AppArmor-related stuff.
  3. File tickets for issues that are out of scope. But first make sure you check the Git history of affected files when you're asking "why?", it'll save us both some time. This initial research might take more than 5 minutes.

Thanks in advance!

Also available in: Atom PDF