Project

General

Profile

Bug #9949

Audit AppArmor policy vs. hard links

Added by intrigeri almost 4 years ago. Updated 4 months ago.

Status:
Rejected
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
08/08/2015
Due date:
% Done:

20%

Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:


Related issues

Related to Tails - Feature #7724: Sandbox I2P Confirmed 11/17/2015
Related to Tails - Feature #12125: Mount a tmpfs on /var/tmp, to mitigate the hardlinks permissions open by the user-tmp AppArmor abstraction Resolved 01/09/2017

History

#1 Updated by intrigeri almost 4 years ago

  • Parent task set to #9534

#2 Updated by intrigeri almost 4 years ago

#3 Updated by intrigeri almost 4 years ago

  • Subject changed from Audit AppArmor policy vs. hardlinks to Audit AppArmor policy vs. hard links
  • Status changed from Confirmed to In Progress
  • % Done changed from 0 to 10

One can look for rules that allow creation of hard links this way:

sudo rgrep -P '[a-zA-Z]*l[a-zA-Z],$' /etc/apparmor.d/

On 1.5~rc1 it outputs:

/etc/apparmor.d/abstractions/base:  owner @{HOME}/.Private/** mrixwlk,
/etc/apparmor.d/abstractions/base:  owner @{HOMEDIRS}/.ecryptfs/*/.Private/** mrixwlk,
/etc/apparmor.d/abstractions/i2p:  owner /{,var/}tmp/**                                    rwklm,
/etc/apparmor.d/abstractions/launchpad-integration:    /** rwlk,
/etc/apparmor.d/abstractions/php5:  /var/lib/php5/session_mm_* rwlk,
/etc/apparmor.d/abstractions/php5:  /var/lib/php5/sess_* rwlk,
/etc/apparmor.d/abstractions/php5:  /tmp/.ZendSem.* rwlk,
/etc/apparmor.d/torbrowser:  deny owner /var/tmp/**     rwklx,
/etc/apparmor.d/torbrowser:  deny /var/tmp/             rwklx,
/etc/apparmor.d/torbrowser:  deny owner /tmp/**         rwklx,
/etc/apparmor.d/torbrowser:  deny /tmp/                 rwklx,
/etc/apparmor.d/usr.sbin.avahi-daemon:  capability kill,
/etc/apparmor.d/usr.sbin.tcpdump:  capability sys_module,

Let's go through it:

  • base: that's for ecryptfs, unused in Tails
  • i2p: looks like this allows I2P to work around its AppArmor policy, basically downgrading to DAC for any file that's on the same filesystem as /tmp or /var/tmp; both are currently on the root filesystem, so at least persistent files should be safe;
  • launchpad-integration: that one is wide open anyway (and it's actually its purpose), so allowing hard links doesn't change much here; we disabled it in 1.5~rc1 for all profiles (namely: the Pidgin one) that included that abstraction;
  • php5: unused in Tails;
  • torbrowser: these are deny rules so we're good;
  • avahi-daemon and tcpdump: false positives triggered by my suboptimal regexp.

Next steps:

  • consider writing an automated test that looks for such potential issues; it'll need a whitelist of known-acceptable occurrences;
  • mention this topic in the relevant design doc.

#4 Updated by intrigeri almost 4 years ago

  • Priority changed from Normal to Elevated
  • Target version changed from Tails_1.6 to Tails_1.7

#5 Updated by intrigeri over 3 years ago

  • Related to Bug #10463: Mention the hardlinks topic in our AppArmor design doc added

#6 Updated by intrigeri over 3 years ago

  • Related to Bug #10462: Automatically test our AppArmor policy vs. hard links added

#7 Updated by intrigeri over 3 years ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (intrigeri)
  • % Done changed from 10 to 100

Audit is done, filed #10462 and #10463 for the next steps.

#8 Updated by intrigeri over 3 years ago

  • Related to deleted (Bug #10462: Automatically test our AppArmor policy vs. hard links)

#9 Updated by intrigeri over 3 years ago

  • Status changed from Resolved to In Progress
  • Target version changed from Tails_1.7 to Tails_1.8
  • % Done changed from 100 to 20

Oops. My regexp was too tight, there are actually lots more stuff to investigate:

sudo rgrep -P '[a-zA-Z]*l[a-zA-Z]*,$' /etc/apparmor.d/ 

#10 Updated by intrigeri over 3 years ago

  • Related to deleted (Bug #10463: Mention the hardlinks topic in our AppArmor design doc)

#11 Updated by intrigeri over 3 years ago

  • Blocks Bug #10462: Automatically test our AppArmor policy vs. hard links added

#12 Updated by intrigeri over 3 years ago

In passing, we may want to mount a dedicated filesystem on /tmp and /var/tmp, to mitigate the hardlinks permissions open by user-tmp. Asked for confirmation that I got it right: https://lists.ubuntu.com/archives/apparmor/2015-November/008750.html

#13 Updated by sajolida over 3 years ago

  • Assignee set to intrigeri

Hey intrigeri, between #9949#note-7 and #9949#note-9 you reopened the ticket but didn't assign it to you again nor did you made it clear that you were giving up on this. Was that on purpose?

#14 Updated by intrigeri over 3 years ago

Hey intrigeri, between #9949#note-7 and #9949#note-9 you reopened the ticket but didn't assign it to you again

That was a mistake, thanks for catching it!

#15 Updated by intrigeri over 3 years ago

  • Target version changed from Tails_1.8 to Tails_2.2

#16 Updated by intrigeri over 3 years ago

  • Target version changed from Tails_2.2 to Tails_2.4

#17 Updated by intrigeri about 3 years ago

  • Target version changed from Tails_2.4 to Tails_2.6

#18 Updated by anonym almost 3 years ago

  • Priority changed from Elevated to Normal

#19 Updated by anonym almost 3 years ago

  • Priority changed from Normal to Elevated

Whoops...

#20 Updated by intrigeri almost 3 years ago

  • Target version changed from Tails_2.6 to Tails_2.7

#21 Updated by intrigeri over 2 years ago

  • Target version changed from Tails_2.7 to 284

#22 Updated by anonym over 2 years ago

  • Target version changed from 284 to Tails 2.10

#23 Updated by intrigeri over 2 years ago

So, it's not as bad as it seemed initially:

To sum up, adding the link permission in the policy a program is confined with will not allow it to create a hard link to a file that that policy denies access to. So, using hard links to escape the sandbox via confined PROGRAM_1 requires the attacker to also have taken control of the system in another way, in order to create the hard link in the first place, e.g. by taking control of another program (PROGRAM_2), that is itself allowed to create the hard link, e.g. because it's not confined by AppArmor at all, or because it is confined with a looser policy. Still, such a scenario can happen: perhaps PROGRAM_2 can't exfiltrate data for some reason, while PROGRAM_1 can, and then exploiting PROGRAM_2 is not enough, the attacker needs to do that (to create a hard link in a place that PROGRAM_1 can read from) and then exploit PROGRAM_1 to exfiltrate the data: IOW, as John Johansen put it, "cooperating tasks with different profiles could potentially leverage hard links to circumvent certain restrictions".

So, it's still useful to look at what kind of 'l' permissions we give in our AppArmor policy, but not from the PoV I had initially (i.e. detecting when that permission could allow the confined program to create a hard link in order to access data outside of its sandbox, which as explained above is not possible). Instead, it's useful to identify confined programs whose policy allow them to play the role of PROGRAM_2 described above.

Also:

In passing, we may want to mount a dedicated filesystem on /tmp and /var/tmp, to mitigate the hardlinks permissions open by user-tmp.

... still makes sense. On Tails 2.9.1, I see that /tmp is a tmpfs already, but /var/tmp is not => #12125.

#24 Updated by intrigeri over 2 years ago

  • Related to Feature #12125: Mount a tmpfs on /var/tmp, to mitigate the hardlinks permissions open by the user-tmp AppArmor abstraction added

#25 Updated by intrigeri over 2 years ago

  • Target version changed from Tails 2.10 to Tails_2.11

#26 Updated by intrigeri over 2 years ago

  • Target version changed from Tails_2.11 to Tails_2.12

#27 Updated by intrigeri over 2 years ago

  • Target version changed from Tails_2.12 to Tails_3.1

I'm too busy until the 3.0 release.

#28 Updated by intrigeri about 2 years ago

  • Target version changed from Tails_3.1 to Hole in the Roof

I've been postponing this for too long and will focus on 3.0 regressions during the 3.1 cycle.

#29 Updated by intrigeri about 2 years ago

  • Target version deleted (Hole in the Roof)

#30 Updated by intrigeri about 2 years ago

  • Priority changed from Elevated to Normal

#31 Updated by intrigeri 11 months ago

  • Assignee deleted (intrigeri)
  • Priority changed from Normal to Low

#32 Updated by intrigeri 4 months ago

  • Parent task deleted (#9534)

(I want to close #9534.)

#33 Updated by intrigeri 4 months ago

  • Blocks deleted (Bug #10462: Automatically test our AppArmor policy vs. hard links)

#34 Updated by intrigeri 4 months ago

  • Status changed from In Progress to Rejected

Feel free to reopen if you want to work on this :)

#35 Updated by xin 4 months ago

  • Description updated (diff)

Also available in: Atom PDF