Bug#877581: apparmor: Ensure Linux 4.14 does not break abstractions/nameservice

2017-11-12 Thread intrigeri
Hi!

Vincas Dargis:
> Since network mediation is reverted from 4.14 (sorry have no link to
> cite), is this still a blocker?

You're correct in that this task does not block the whole "enabling
AppArmor by default" plan anymore, since we have pinned the Linux 4.13
feature set and such pinning was "repaired" (with a revert of the
entire code that works fineā€¦ except when pinning is used) in 4.14.

This task still blocks #880078 though. Given socket mediation was
reverted, I believe the only new features that could break stuff once
we bump the pinned feature set to 4.14's are mount and signal mediation.

> Do we need to "sprint" for 4.14-possibly-introducing issues?

I'm not sure how urgently we should handle #880078 and (transitively)
#877581. I'd welcome your input about it on #880078, where I've
started discussing the pros & cons.

Cheers,
-- 
intrigeri



Bug#877581: apparmor: Ensure Linux 4.14 does not break abstractions/nameservice

2017-11-12 Thread Vincas Dargis
Since network mediation is reverted from 4.14 (sorry have no link to cite), is this still a blocker? Do we need to 
"sprint" for 4.14-possibly-introducing issues?




Bug#877581: [pkg-apparmor] Bug#877581: Bug#877581: apparmor: Ensure Linux 4.14 does not break abstractions/nameservice

2017-10-24 Thread intrigeri
When testing stuff on 4.14, make sure you:

 - use apparmor 2.11.1

 - disable features-files= in /etc/apparmor/parser.conf (otherwise not
   only you'll be stuck to 4.13's feature set and unable to do useful
   work here, but worse you'll hit a kernel bug wrt. feature set
   pinning & network rules that totally breaks unix/netlink/etc.)



Bug#877581: apparmor: Ensure Linux 4.14 does not break abstractions/nameservice

2017-10-24 Thread intrigeri
Vincas Dargis:
> On 2017.10.12 07:37, intrigeri wrote:
>> I suspect more is coming. Ubuntu / OpenSUSE probably already have
>> some of this stuff.

> Could you clarify, why Ubuntu should have issues, if they had
> network mediation before?

You're right, Ubuntu should not be affected by this problem (I was
reasoning in terms of "they do stuff upstream first now", but so far
they've mostly been working on the backlog created by the previous
development model i.e. stuff they're already applying to their own
kernel).

Cheers,
-- 
intrigeri



Bug#877581: [pkg-apparmor] Bug#877581: Bug#877581: apparmor: Ensure Linux 4.14 does not break abstractions/nameservice

2017-10-23 Thread intrigeri
Christian Boltz:
> It turned out that the added "network unix dgram/stream" rules are not 
> really needed. Let me explain ;.-)

> In theory apparmor_parser should downgrade the "unix" rules in 
> abstractions/base to "network unix" rules (when using Kernel < 4.15), 
> which allows more than "network unix dgram/stream".

> In practise this rule downgrade was broken in apparmor_parser, and got 
> fixed in AppArmor 2.11.1, 2.10.3 and 2.9.5.

> So once you update apparmor_parser to one of these versions, profiles 
> that include abstractions/base (which basically means all profiles) 
> should no longer need the "network unix dgram/stream" rules.

Great! I'm packaging 2.11.1 as we speak, so I've reverted your patch
(that I had previously applied to our packaging bzr repo, but did not
upload to Debian yet). Thanks for the heads up!

> Note that the patch discussed in this bugreport adds a few other rules - 
> those will still be needed.

Indeed. I want to work on this later this week.

Cheers,
-- 
intrigeri



Bug#877581: [pkg-apparmor] Bug#877581: apparmor: Ensure Linux 4.14 does not break abstractions/nameservice

2017-10-20 Thread Christian Boltz
Hello,

Am Donnerstag, 12. Oktober 2017, 18:18:53 CEST schrieb Vincas Dargis:
> Could you clarify, why Ubuntu should have issues, if they had network
> mediation before?

It turned out that the added "network unix dgram/stream" rules are not 
really needed. Let me explain ;.-)

In theory apparmor_parser should downgrade the "unix" rules in 
abstractions/base to "network unix" rules (when using Kernel < 4.15), 
which allows more than "network unix dgram/stream".

In practise this rule downgrade was broken in apparmor_parser, and got 
fixed in AppArmor 2.11.1, 2.10.3 and 2.9.5.

So once you update apparmor_parser to one of these versions, profiles 
that include abstractions/base (which basically means all profiles) 
should no longer need the "network unix dgram/stream" rules.

This also explains why Ubuntu users didn't see this problem - their 
kernel supports 'unix' rules since years, so the rule downgrade to 
'network unix' was not needed.


Note that the patch discussed in this bugreport adds a few other rules - 
those will still be needed.


Regards,

Christian Boltz
-- 
> All cats purr at 28hz.
I think your cats need tuning - according to a couple of quick measure-
ments on a recently calibrated reference cat, the dominant frequency of
a correctly adjusted cat should be 12Hz +/-20%.  [Lionel Lauer]


signature.asc
Description: This is a digitally signed message part.


Bug#877581: apparmor: Ensure Linux 4.14 does not break abstractions/nameservice

2017-10-12 Thread Vincas Dargis

On 2017.10.12 07:37, intrigeri wrote:

I suspect more is coming. Ubuntu / OpenSUSE probably already have
some of this stuff.


Could you clarify, why Ubuntu should have issues, if they had network mediation 
before?



Bug#877581: apparmor: Ensure Linux 4.14 does not break abstractions/nameservice

2017-10-11 Thread intrigeri
Control: retitle -1 apparmor: Ensure our AppArmor policy does not break stuff 
with Linux 4.14
Control: tag -1 - patch
Control: tag -1 - pending

I've upgraded my system to 4.14 and had to adjust no less than 7 profiles
*after* applying Christian's patch to abstractions/nameservice.

They're spread over multiple source packages but I figured it would be
nice to at least share my tweaks (attached) so anyone affected can
temporarily apply them locally, and everyone who wants can start
pushing them to the correct upstream / source package.

I suspect more is coming. Ubuntu / OpenSUSE probably already have
some of this stuff.

diff --git a/apparmor.d/abstractions/nameservice b/apparmor.d/abstractions/nameservice
index 6c9bde39..4322cf17 100644
--- a/apparmor.d/abstractions/nameservice
+++ b/apparmor.d/abstractions/nameservice
@@ -89,6 +89,12 @@
   network inet  dgram,
   network inet6 dgram,
 
+  # TODO: replace with more specific "unix" rules once support for them
+  # arrives in the Linux kernel (probably in 4.15) and gives us detailed
+  # log messages
+  network unix dgram,
+  network unix stream,
+
   # TODO: adjust when support finer-grained netlink rules
   # Netlink raw needed for nscd
   network netlink raw,
diff --git a/apparmor.d/abstractions/tor b/apparmor.d/abstractions/tor
index 15601a4a..5e494adc 100644
--- a/apparmor.d/abstractions/tor
+++ b/apparmor.d/abstractions/tor
@@ -6,6 +6,8 @@
   network tcp,
   network udp,
 
+  network unix dgram,
+
   capability chown,
   capability dac_read_search,
   capability fowner,
diff --git a/apparmor.d/sbin.dhclient b/apparmor.d/sbin.dhclient
index 7b6a06d8..17723dab 100644
--- a/apparmor.d/sbin.dhclient
+++ b/apparmor.d/sbin.dhclient
@@ -16,6 +16,9 @@ profile dhclient /{usr/,}sbin/dhclient {
   network packet,
   network raw,
 
+  network unix dgram,
+  network unix stream,
+
   @{PROC}/[0-9]*/net/ r,
   @{PROC}/[0-9]*/net/** r,
 
@@ -89,12 +92,15 @@ profile dhclient /{usr/,}sbin/dhclient {
 
   /run/NetworkManager/private-dhcp rw,
   signal (send) peer=/{usr/,}sbin/dhcient,
+  signal (send) peer=dhcient,
 
   /var/lib/NetworkManager/*lease r,
   signal (receive) peer=/usr/sbin/NetworkManager,
   ptrace (readby) peer=/usr/sbin/NetworkManager,
   network inet dgram,
   network inet6 dgram,
+
+  network unix stream,
 }
 
 /usr/lib/connman/scripts/dhclient-script {
diff --git a/apparmor.d/torbrowser.Browser.firefox b/apparmor.d/torbrowser.Browser.firefox
index 1d6421e7..3ec73b0f 100644
--- a/apparmor.d/torbrowser.Browser.firefox
+++ b/apparmor.d/torbrowser.Browser.firefox
@@ -10,6 +10,7 @@
   # @{HOME}/ r,
 
   #dbus,
+  network netlink raw,
   network tcp,
 
   deny /etc/host.conf r,
diff --git a/apparmor.d/usr.bin.pulseaudio b/apparmor.d/usr.bin.pulseaudio
index 20d5bc25..2817ab55 100644
--- a/apparmor.d/usr.bin.pulseaudio
+++ b/apparmor.d/usr.bin.pulseaudio
@@ -25,6 +25,8 @@
   unix (connect, receive, send) type=stream peer=(addr="@/tmp/.ICE-unix/[0-9]*"),
   ptrace (read,trace) peer=@{profile_name},
 
+  network unix dgram,
+
   /usr/bin/pulseaudio mixr,
 
   /etc/pulse/ r,
diff --git a/apparmor.d/usr.sbin.cupsd b/apparmor.d/usr.sbin.cupsd
index 053d1c1f..ca884e2d 100644
--- a/apparmor.d/usr.sbin.cupsd
+++ b/apparmor.d/usr.sbin.cupsd
@@ -47,6 +47,8 @@
   network econet dgram,
   network ash dgram,
 
+  network unix stream,
+
   /{usr/,}bin/bash ixr,
   /{usr/,}bin/dash ixr,
   /{usr/,}bin/hostname ixr,
diff --git a/apparmor.d/usr.sbin.haveged b/apparmor.d/usr.sbin.haveged
index 0e611388..ad1bee6d 100644
--- a/apparmor.d/usr.sbin.haveged
+++ b/apparmor.d/usr.sbin.haveged
@@ -7,6 +7,8 @@
   # Required for ioctl RNDADDENTROPY
   capability sys_admin,
 
+  network unix stream,
+
   owner @{PROC}/@{pid}/status r,
 
   @{PROC}/sys/kernel/osrelease r,
diff --git a/apparmor.d/usr.sbin.libvirtd b/apparmor.d/usr.sbin.libvirtd
index 4c4a751c..e905c95c 100644
--- a/apparmor.d/usr.sbin.libvirtd
+++ b/apparmor.d/usr.sbin.libvirtd
@@ -37,9 +37,16 @@
   network packet dgram,
   network packet raw,
 
+  network netlink raw,
+  network unix dgram,
+  network unix stream,
+
   ptrace (trace) peer=unconfined,
   ptrace (trace) peer=/usr/sbin/libvirtd,
   ptrace (trace) peer=libvirt-*,
+  ptrace (trace) peer=/usr/sbin/dnsmasq,
+
+  signal (send) set=("hup") peer=/usr/sbin/dnsmasq,
 
   # Very lenient profile for libvirtd since we want to first focus on confining
   # the guests. Guests will have a very restricted profile.


Bug#877581: apparmor: Ensure Linux 4.14 does not break abstractions/nameservice

2017-10-03 Thread intrigeri
Package: apparmor
Version: 2.11.0-11
Severity: important

This bug is meant to track
https://lists.alioth.debian.org/pipermail/pkg-apparmor-team/2017-October/001755.html

We should apply this patch as a temporary workaround before Linux 4.14
reaches Debian (ideally, before it reaches experimental).