Bug #9949

Audit AppArmor policy vs. hard links

Added by intrigeri 2015-08-08 02:44:56 . Updated 2019-03-10 10:31:13 .

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

20%

Feature Branch:
Type of work:
Research
Blueprint:

Starter:
Affected tool:
Deliverable for:

Description

https://lists.autistici.org/message/20150808.101001.88759d52.en.html

Subtasks

Related issues

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

History

#1 Updated by intrigeri 2015-08-08 02:45:41

#2 Updated by intrigeri 2015-08-08 03:00:33

#3 Updated by intrigeri 2015-08-08 03:04:38

  • 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 2015-09-22 12:18:12

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

#5 Updated by intrigeri 2015-11-01 04:23:52

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

#6 Updated by intrigeri 2015-11-01 04:24:25

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

#7 Updated by intrigeri 2015-11-01 04:25:11

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

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

#8 Updated by intrigeri 2015-11-01 04:38:18

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

#9 Updated by intrigeri 2015-11-01 04:41:58

  • 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 2015-11-01 04:42:17

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

#11 Updated by intrigeri 2015-11-01 04:42:30

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

#12 Updated by intrigeri 2015-11-01 05:06:06

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 2015-11-03 12:22:46

  • Assignee set to intrigeri

Hey intrigeri, between Bug #9949#note-7 and Bug #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 2015-11-04 02:14:43

> Hey intrigeri, between Bug #9949#note-7 and Bug #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 2015-12-14 09:33:08

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

#16 Updated by intrigeri 2016-02-05 20:52:11

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

#17 Updated by intrigeri 2016-04-29 15:41:52

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

#18 Updated by anonym 2016-08-16 13:33:10

  • Priority changed from Elevated to Normal

#19 Updated by anonym 2016-08-16 13:34:50

  • Priority changed from Normal to Elevated

Whoops…

#20 Updated by intrigeri 2016-08-31 06:06:12

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

#21 Updated by intrigeri 2016-11-05 13:59:44

  • Target version changed from Tails_2.7 to 284

#22 Updated by anonym 2016-11-25 10:57:15

  • Target version changed from 284 to Tails 2.10

#23 Updated by intrigeri 2017-01-09 19:14:00

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 => Feature #12125.

#24 Updated by intrigeri 2017-01-09 19:27:34

  • 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 2017-01-24 13:47:12

  • Target version changed from Tails 2.10 to Tails_2.11

#26 Updated by intrigeri 2017-03-08 09:00:36

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

#27 Updated by intrigeri 2017-04-03 07:58:15

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

I’m too busy until the 3.0 release.

#28 Updated by intrigeri 2017-06-05 13:32:25

  • 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 2017-06-05 14:08:29

  • Target version deleted (Hole in the Roof)

See Bug #9534#note-14.

#30 Updated by intrigeri 2017-06-05 14:21:55

  • Priority changed from Elevated to Normal

#31 Updated by intrigeri 2018-08-18 09:16:30

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

#32 Updated by intrigeri 2019-03-07 15:46:59

(I want to close Bug #9534.)

#33 Updated by intrigeri 2019-03-07 15:47:13

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

#34 Updated by intrigeri 2019-03-08 15:42:58

  • Status changed from In Progress to Rejected

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

#35 Updated by xin 2019-03-10 10:31:13

  • Description updated