2

I generated an apparmor profile for the tor binary that comes bundled in Ricochet:

# Last Modified: Sun Apr  2 2017
#include <tunables/global>

/ricochet/*-ricochet/tor {
  #include <abstractions/base>

  deny /etc/ld.so.preload r,

  deny /proc/sys/kernel/random/uuid r,
  /ricochet/*-ricochet/config/tor/ rwk,
  /ricochet/*-ricochet/config/tor/ r,
  /ricochet/*-ricochet/config/tor/cached-certs r,
  /ricochet/*-ricochet/config/tor/cached-microdesc-consensus r,
  /ricochet/*-ricochet/config/tor/cached-microdescs r,
  /ricochet/*-ricochet/config/tor/cached-microdescs.new r,
  /ricochet/*-ricochet/config/tor/control-port w,
  /ricochet/*-ricochet/config/tor/control-port.tmp rw,
  /ricochet/*-ricochet/config/tor/default_torrc r,
  /ricochet/*-ricochet/config/tor/lock rwk,
  /ricochet/*-ricochet/config/tor/state rw,
  /ricochet/*-ricochet/config/tor/state.tmp rw,
  /ricochet/*-ricochet/config/tor/torrc r,
  /ricochet/*-ricochet/tor mr,
  deny /sys/devices/system/cpu/ r,
  /usr/share/tor/geoip r,
  /usr/share/tor/geoip6 r,

}

Not sure how sensitive /proc/sys/kernel/random/uuid are so I denied them. Ricochet opens fine with them denied. Tell me if I should allow them though...

My biggest concern is /usr/share/tor/geoip. I have it set to read-only but I'm still getting journalctl complaints:

$ journalctl -af
Apr 02 <uname removed> kernel: audit: type=1400 audit(1491170231.720:200): apparmor="DENIED" operation="open" profile="/ricochet/<removed>-ricochet/tor" name="/usr/share/tor/geoip" pid=2563 comm="tor" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
Apr 02 <uname removed> kernel: audit: type=1400 audit(1491170231.720:201): apparmor="DENIED" operation="open" profile="/ricochet/<removed>-ricochet/tor" name="/usr/share/tor/geoip6" pid=2563 comm="tor" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

Can anyone help me debug this? Why is apparmor denying r access?

1

Did you both reload AppArmor and restart the application? Simply reloading AppArmor does not mean changes to the policy will take effect immediately. If that does not work, you can whitelist the entirety of /usr/share/tor. It is only writable by root, so there is no issue with malicious programs modifying it, and it does not contain any sensitive information. It is not writable, so you wouldn't benefit from more fine-grained control over it. Simply letting Tor read anything inside it is perfectly safe:

/usr/share/tor/ r,
/usr/share/tor/** r,

As for /proc/sys/kernel/random/uuid, it is not sensitive. All it does is return random data formatted as a UUID. It provides no more information than /dev/urandom does. From proc(5):

/proc/sys/kernel/random/uuid (since Linux 2.4)
    Each read from this read-only file returns a randomly generated
    128-bit UUID, as a string in the standard UUID format.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.