Hi,
FWIW I've been using dracut without any such issue in a similar setup
on my laptop for 2.5 years: my root filesystem is on a LV that's in
a VG whose only PV is a LUKS-encrypted partition.
Cheers!
this is a duplicate of https://bugs.debian.org/879900.
Until someone focuses on preparing a proposed update for Stretch,
please install the profile from apparmor-profiles-extra/testing.
Cheers,
--
intrigeri
Salvatore Bonaccorso:
> On Mon, Jan 08, 2018 at 01:46:54AM -0800, John Johansen wrote:
>> On 01/06/2018 07:50 AM, intrigeri wrote:
>> > What's the status of this patch?
>> >
>> it is in 4.15-rc7, and has started working its way into the 4.14 stable
>&
Control: reassign -1 linux-image-4.14.0-2-amd64
Control: found -1 4.14.7-1
Laszlo KERTESZ:
> So it happened again with no apparmor loaded.Twice.
Thanks for reporting! I'm therefore reassigning this bug to the
affected Linux kernel package.
Cheers,
--
intrigeri
(and label it "Team upload", no need to call it a NMU).
Cheers,
--
intrigeri
hat this is caused by backupninja's postgresql jobs.
Can you please share the output of `backupninja --now --debug'?
(Make sure it does not contain any password :)
Cheers,
--
intrigeri
Control: tag -1 + patch
Hi!
Sebastian Andrzej Siewior:
> On 2018-01-07 14:59:54 [+0100], intrigeri wrote:
>> So with my AppArmor in Debian maintainer hat, I would find it
>> reasonable if the clamav-daemon maintainers decided to leave it as-is,
>> possibly improving a li
intrigeri:
> Rene Engelhard:
>> done already, though in complain mode..
> Thanks! I'll follow up on the next steps on a new bug report, quoting
> the useful bits from this one :)
FTR that's #886548.
intrigeri:
> intrigeri:
>> Dear upstream/parser developers, would it feel crazy to modify
>> clear_cache_cb to ignore the passed file if its basename is
>> CACHEDIR.TAG? Or should _aa_dirat_for_each get a list of excluded file
>> names as a new argument, or something s
enforce mode instead. See #883800 for the beginning of
this conversation.
The remaining blocker seems to be autopkgtests being broken by
AppArmor, due to using custom paths:
René Engelhard wrote:
> intrigeri wrote:
>> You mentioned something elsewhere about the LibreOffice test suite
>>
Rene Engelhard:
> done already, though in complain mode..
Thanks! I'll follow up on the next steps on a new bug report, quoting
the useful bits from this one :)
Cheers,
--
intrigeri
Control: affects -1 - clamav-daemon
Control: reassign -1 clamav-daemon
Hi,
Francois Gouget:
> Intrigeri wrote:
>> Can you please provide the corresponding AppArmor denial logs you'll
>> find in the Journal or in kern.log?
> Here is a short extract:
> Dec 26 12
enough to help you debug this problem or do you need more info?
Cheers,
--
intrigeri
intrigeri:
> Dear upstream/parser developers, would it feel crazy to modify
> clear_cache_cb to ignore the passed file if its basename is
> CACHEDIR.TAG? Or should _aa_dirat_for_each get a list of excluded file
> names as a new argument, or something similar?
> If any of these a
e!
Cheers,
--
intrigeri
Control: tag -1 + fixed-upstream
Control: tag -1 + pending
Adrian Heine:
> thanks for the help! I created
> https://gitlab.com/apparmor/apparmor-profiles/merge_requests/7.
Thanks a lot :)
I've merged this upstream and imported the updated profile in our Vcs-Git.
Cheers,
--
intrigeri
(#882697)
Cheers,
--
intrigeri
ould remove the "confirmed" and/or "pending" tag
so in doubt I'll leave it to you to do the right thing.
Cheers,
--
intrigeri
Hi,
good catch! It would be interesting to know how other distros
handle this.
Cheers,
--
intrigeri
t upstream last July:
https://gitlab.com/apparmor/apparmor/commit/ff66ca90390d14fa710ac28cc20728f934152724
… which will reach Debian once I package the recent 2.12 upstream release.
Cheers,
--
intrigeri
upstream in AppArmor itself:
https://gitlab.com/apparmor/apparmor/commit/ff66ca90390d14fa710ac28cc20728f934152724
… which will make it into Debian once we package AppArmor 2.12.
Cheers,
--
intrigeri
Hi John,
John Johansen:
> Attached is the patch for the kernel that is currently in testing
> From 1aa96ec6d0fce613e06fa4d073c8cf3e183989da Mon Sep 17 00:00:00 2001
> From: John Johansen
> Date: Thu, 7 Dec 2017 00:28:27 -0800
> Subject: [PATCH] apparmor: fix regression in mount mediation when fe
e with the proposed simplification idea. I didn't do a full code
review though.
Cheers,
--
intrigeri
Hi,
in case it might help other Live systems still using aufs for some
reason, for the record I've implemented a workaround to this bug in
Tails:
https://git-tails.immerda.ch/tails/tree/config/chroot_local-patches/live-boot:_workaround_aufs_bug.patch?h=feature/14976-linux-4.14%2bforce-all-test
Diederik de Haas:
> I was indeed wondering whether it would be useful to report because of that.
> As you noticed I did decide to report it and add the upstream tag because of
> it, but I can understand closing it :)
:)
> If more ppl would report it, you could chose to reopen it so it would be
/tmp/ro=rr+wh aufs /tmp/mount \
&& ls /tmp/mount ; \
ls /tmp/mount
Segmentation fault
bla
I've tested replacing that first read access with a write access,
same result.
(Off-topic: I'll try to implement a workaround in live-boot.)
Cheers,
--
intrigeri
rsions of packages aufs-dkms recommends:
ii aufs-tools 1:4.9+20170918-1
Versions of packages aufs-dkms suggests:
pn aufs-dev
-- no debconf information
--
intrigeri
a library so
> AppArmor confinement doesn't matter there.
… I think leaving this bug open and wontfix for a little while is
a suitable approach. If someone on the team prefers to close it,
I don't mind.
Cheers,
--
intrigeri
Control: severity -1 serious
Roger Shimizu:
> I confirmed that there's only one package need to be installed
> specifically: libdbus-glib-1-2
[...]
> I'll only add libdbus-glib-1-2 as dependency.
Thanks for confirming. Making this bug RC then, as per policy.
Cheers,
--
intrigeri
Control: tag -1 + patch
Ronny Standtke:
> The attached patch (against the current version in git) fixes this issue.
Looks good to me.
intrigeri:
> I intend to proceed with the removal request if nobody objects within
> another 2 months.
Done: #885913
(last time I checked, inst:74 / vote: 14). It's been
orphaned back in March. I've proposed removing perlpanel 5 months ago
(#870417) and nobody objected so I think we can now go ahead.
Cheers,
--
intrigeri
Package: ftp.debian.org
Severity: normal
Hi!
The GNOME team is going to drop libgnome and related libraries in
Buster. This is one of the few packages that still depend on the
corresponding Perl bindings.
Approval of the current maintainer: https://bugs.debian.org/868410
Cheers,
--
intrigeri
lim) hope that someone steps up.
Did this happen?
Updates:
- The GNOME team is now bumping severity on bugs that block the
removal of libgnome*.
- shutter transitively depends on libunique that shall go away as
well (#885811).
Cheers,
--
intrigeri
.14 too
Do you need more info from me or from the bug reporter (Kertesz
Laszlo, Cc'ed)?
Cheers,
--
intrigeri
tag 773346 pending
thanks
Date: Thu Oct 26 16:18:19 2017 +
Author: intrigeri
Commit ID: f2cc06d6696a35288f109681d57fd313b6334627
Commit URL:
https://anonscm.debian.org/cgit/reportbug/reportbug.git;a=commitdiff;h=f2cc06d6696a35288f109681d57fd313b6334627
Patch URL:
https
#x27;t know how to
fix this, and IMO we should not block on it before we address the bug
I'm reporting here, but perhaps it's worth a NEWS.Debian entry?
Cheers,
--
intrigeri
Next step is probably: whoever wants to see this happen works on it
and proposes a branch or patch.
Cheers,
--
intrigeri
ready, only
# apparmor_parser -r /path/to/ntpd/profile
is missing :)
> When I googled the issue, the most prominent results were to disable any
> SElinux / apparmor. And this is definitely the worst option ;-)
Exactly.
Cheers,
--
intrigeri
x upstream
yourself directly?
If you are:
1. fork https://gitlab.com/apparmor/apparmor-profiles
2. edit the ubuntu/18.04/usr.bin.pidgin file and commit (ideally,
reference this bug report)
3. submit a merge request
Otherwise, no problem, someone on the Debian AppArmor team will pick
it up :)
Cheers,
--
intrigeri
Hi QEMU maintainers!
intrigeri:
> 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 :)
I've just seen another Stretch user face this bug again, and wonder
why the
bc6 2.25-3
> ii lsb-base 9.20170808
> ii python33.6.3-2
> apparmor recommends no packages.
> Versions of packages apparmor suggests:
> pn apparmor-profiles
> pn apparmor-profiles-extra
> pn apparmor-utils
> -- debconf information:
> apparmor/homedirs:
--
intrigeri
Control: severity -1 minor
(We ship this profile in complain mode by default, and apart of noise
in the logs, no actual functionality breakage was reported.)
ter, the system hang. No error
> message appeared, no clue pointed to missing apparmor.
Sorry about that. How did you draw the conclusion that this system
hang was caused by deinstalling the apparmor package?
Cheers,
--
intrigeri
Santiago R.R.:
> On Mon, 16 Jan 2017 17:50:15 +0100 intrigeri wrote:
>> santiag...@riseup.net:
>> > I am not expert on writing systemd units, and I am unable to play with
>> > this soon. So it would be great if you could propose a patch :-)
>>
>> Sure. I m
such uncommon customization
applied locally by sysadmins, other than education and documentation
about AppArmor so they're able to adjust their AppArmor
configuration accordingly.
Regards,
--
intrigeri
Hi pkg-privacy-tools & fteproxy maintainers!
Nicolas Braud-Santoni:
> On Mon, Dec 11, 2017 at 07:21:50AM +0100, intrigeri wrote:
>> I suggest first checking why we're still including obfsproxy:
>> I suspect most of the reverse-dependency relationships might be
>&g
Martin:
> I can confirm that the changes from commit
>> https://gitlab.com/apparmor/apparmor/commit/cc5a23d4c1236a0221f7bae0fd3d59f583ec9a1d
> fix the problem.
Thanks!
e AppArmor 2.11.95
(aka. 2.12~beta1), unless someone wants to cherry-pick this commit as
a Debian patch for now.
Cheers,
--
intrigeri
Control: tag -1 + fixed-upstream
Héctor Orón Martínez:
> FYI patch got merged upstream:
> https://gitlab.com/apparmor/apparmor/commit/b24a1c4d546a6825f252d27243e09c80d04cf484
Congrats! Tagging this bug accordingly :)
Armor confining
matters, I'm fine with us including a profile again *if* someone
commits to maintaining it, which apparently is hard to do properly
without routinely using it on testing/sid.
Thanks!
Cheers,
--
intrigeri
Jan Luca Naumann:
> I have already prepared an upload but there was a seg fault on my test
> system I want to investigate before uploading.
Great, thanks for the update!
Hi,
Laurent Bigonville:
> if a policy creator wants to modify the policy he might need to modify this
> file as well same if a user is building his own kernel.
There's really no good reason why one would need to modify the default
file in /usr: the features-file that the parser uses is configured
Control: retitle -1 the upstream test suite does not support usrmerge
intrigeri:
> Can you please send this upstream as a merge request there:
> https://gitlab.com/apparmor/apparmor/
> ?
> If you prefer not to, I can forward. But IIRC it's not your first
> contribution
intrigeri:
> Rene Engelhard:
>>> that everyone else can't benefit from AppArmor security benefits
>>> due to that, so I'm leaning towards:
>>>
>>> 1. keep the AppArmor profile enforced by default, so the vast
>>>
ching AppArmor in Debian is that we want to
avoid creating a culture of "AppArmor breaks stuff so I always disable
it entirely".
Cheers,
--
intrigeri
>From 1afd67ec9f4e68e619f4e707bd62142ba8de78cf Mon Sep 17 00:00:00 2001
From: intrigeri
Date: Thu, 7 Dec 2017 17:34:48 +
Subject: [P
it?
Exactly!
> ACK, thanks for your work!
:)
Cheers,
--
intrigeri
Christian Boltz:
> Am Donnerstag, 7. Dezember 2017, 09:40:04 CET schrieb intrigeri:
>> - disabling use_group in notify.conf, so this (mostly useless AFAICT)
>> check does not harm UX
> Can you please submit this upstream?
Sure, will do!
> I agree that this check is u
ffiles shipped in /etc is a well established system
administration practice, and it should not come as a surprise to any
advanced user who passes a custom profile path to LibreOffice on the
command line.
Cheers,
--
intrigeri
full path?)
If the above does not work, yes.
> One could also just patch it :-)
Absolutely.
Cheers,
--
intrigeri
he proposed change in README.Debian.
> Would be nice.
Great. I'll do this then :)
If you don't mind, once I have a patch I won't build a test package
locally: I suspect src:libreoffice takes a while to build, and my
changes should boil down to setting ENABLE_APPARMOR_PROFILES=y and
adding README.Debian that dh_installdocs should pick up automatically.
Cheers,
--
intrigeri
x27;s 2.11.1).
> I also can't see it being overridden anywhere. So I am not sure why this
> permission should be denied...
Can you please share the content of your
/etc/apparmor.d/abstractions/python file?
Cheers,
--
intrigeri
EDIRS}+=/home/host to
/etc/apparmor.d/tunables/home.d/site.local should do the trick.
Then, "sudo systemctl restart apparmor" and retry.
Does this fix the problem you're experiencing?
Cheers,
--
intrigeri
Fabian Grünbichler:
> sounds like a plan, I'll re-spin my patch later today.
:)
would work (before
the change that prompted the aforementioned merge request)
as documented.
Shall we simply modify aa-complain(8) to make it clearer that one is
supposed to pass the path to the binary that's being confined by the
profile, and not anything else?
Cheers,
--
intrigeri
Hi,
Fabian Grünbichler:
> On Thu, Dec 07, 2017 at 08:47:52AM +0100, intrigeri wrote:
>> > I am not sure whether we are the only derivative/downstream/.. affected
>> > by this change, but it has the potential to break a lot of setups using
>> > their own (more recen
;adm" group to use aa-notify
- disabling use_group in notify.conf, so this (mostly useless AFAICT)
check does not harm UX
So let's not bother tracking this on a new, dedicated bug.
Cheers,
--
intrigeri
o be useful for.
⇒ I'll unset use_group in the next upload of the package to Debian.
Then, if someone explains what use_group is supposed to be useful for,
we can reconsider later :)
Cheers,
--
intrigeri
,mnt,opt,srv}/**. Where are the files you're
trying to play located? If they are in one of the supposedly allowed
directories, please provide the AppArmor denial logs.
Thanks in advance!
Cheers,
--
intrigeri
o me. Thanks to
you I'm now aware of this use case and we can work together to support
it better :)
>> > intrigeri:
>> >> Understood. Ideally parser.conf would be complemented by
>> >> /etc/apparmor/parser.conf.d/*.conf, which could be sourced at the end
>
This is now really "pending": I've merged the fix upstream and pushed
it to our Vcs-Git :)
intrigeri:
> At first glance this very much looks like a bug in the custom kernel
> you're using.
According to #883703 this bug affects the mainline Linux kernel as
well so this stretch-pu may break as many use cases at it'll repair
when running Linux 4.13+ on Stretch :/
Dear r
or sid, I think we should simply bump the pinned feature set to
4.14's: it's easier to fix policy than to deal with kernel bugs.
Cc'ing John so he's aware of this kernel bug.
For Stretch, my proposed update shall be reverted. I'll follow up on
the corresponding release.d.o bug.
:/
Cheers,
--
intrigeri
Hi again Fabian & release team,
Fabian Grünbichler:
> On Wed, Dec 06, 2017 at 03:28:03PM +0100, intrigeri wrote:
>> > it potentially breaks systems using a custom/backports/newer kernel
>> > and AA profiles requiring features not supported by the pinned 4.9
>> >
nfinement becomes weaker,
but the application keeps working.
> since
> both the AA config file itself and the feature set file are conffiles,
> overriding is not easily possible without conffile modification.
Right. Sorry I did not think about this Debian derivative use case.
> I'l
currently..
Right. This looks like a good interim solution to me. Do you want to
try to implement it in the packaging?
> intrigeri:
>> Understood. Ideally parser.conf would be complemented by
>> /etc/apparmor/parser.conf.d/*.conf, which could be sourced at the end
>> of parser.c
at_for_each get a list of excluded file
names as a new argument, or something similar?
If any of these approaches seems acceptable, is anyone around willing
to write this patch, or should I try to find a C person elsewhere?
Thanks in advance!
Cheers,
--
intrigeri
(thanks a lot for working hard on getting AA to work OOTB in Debian BTW
> - long overdue and really looking forward to it!)
Thank you :)
Cheers,
--
intrigeri
Thomas Goirand:
> Do you know if it's possible to generate a Sid live system?
We have weekly builds of testing Live ISO images:
https://get.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/ …
so I don't see any reason why building sid Live systems would be
impossible :)
ofile thunderbird /usr/lib/thunderbird/thunderbird {
+profile thunderbird /usr/lib/thunderbird/thunderbird{,-bin} {
#include
#include
#include
Cheers,
--
intrigeri
ity of cases. Besides, I would feel wrong
to see live-boot automatically removed from testing merely because of
this bug. So perhaps this could be demoted to severity:important?
Cheers,
--
intrigeri
actical or not feasible) so that we're
> ready when 4.14 reaches sid?
Linux 4.14 is now in sid so I think this makes this bug RC.
Cheers,
--
intrigeri
Adam D. Barratt:
> Please go ahead, bearing in mind that the window for getting fixes into
> the 9.3 point release closes during this weekend.
Thanks, uploaded.
Cheers,
--
intrigeri
ce/security
trade-off for Debian?
If it helps making a decision I could hunt for benchmark results (the
KSPP people tend to attach these to their pull requests when it
matters).
[0] https://outflux.net/blog/archives/2017/11/14/security-things-in-linux-v4-14/
Cheers,
--
intrigeri
bian/ directory,
you can directly edit it so it looks like this:
/usr/bin/irssi flags=(complain) {
Cheers,
--
intrigeri
in advance :)
Cheers,
--
intrigeri
t; any problem.
Now that AppArmor is enabled by default in testing/sid, I suspect more
users of Stretch may want to try it out. So it would really be nice
to avoid breaking things for them in case they need a kernel from
backports, e.g. to support newer hardware.
Cheers,
--
intrigeri
atures
+introduced in recent kernels.
+
+ -- intrigeri Sat, 25 Nov 2017 18:04:05 +
+
apparmor (2.11.0-3) unstable; urgency=medium
* Fix CVE-2017-6507: don't unload unknown profiles during package
diff -Nru apparmor-2.11.0/debian/features apparmor-2.11.0/debian/features
--- a
intrigeri:
> Yes. You can delete intrigeri/bugfix-882672 right away, and delete
> intrigeri/bugfix-882672-v2 after you've merged or cherry-picked
> its commits.
You can now delete both.
> So I'll merge my branch myself once I've tested a package built
> from it :)
gt; debugging around the Thunderbird AppArmor profile.
Good idea! I've added a link to the corresponding doc on wiki.d.o
(commit d8dcde6daa on my branch).
> You mean both branches are to delete later?
Yes. You can delete intrigeri/bugfix-882672 right away, and delete
intrigeri/bugfix-88
Control: tag -1 + patch
Hi Carsten,
please review and merge the intrigeri/bugfix-882672-v2 branch (in
Vcs-Git). It would be great to include this change in the next upload
to sid, so that we stop breaking Thunderbird UX with AppArmor :)
I'm now building a package to test my changes, but
Control: reassign -1 apparmor
Control: affects -1 thunderbird
Control: tag -1 + upstream
Control: tag -1 + fixed-upstream
Control: tag -1 - moreinfo
Vincas Dargis:
> Looks like ubuntu-browsers abstraction is fixed in upstream:
> https://gitlab.com/apparmor/apparmor/commit/ff66ca90390d14fa710ac28cc
Control: severity -1 minor
Once AppArmor profile for Thunderbird is disabled by default
(#882672), this bug will only affect users who opt-in.
in Vcs-Git right away.
FTR the two other people who've been actively working on this profile
recently agree with this proposal:
- Simon Deziel:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882218#25
- Vincas Dargis:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=882048#50
Cheers,
--
intrigeri
good enough or we should ship
this profile disabled by default.
Cheers,
--
intrigeri
've been trying
hard to avoid for years.
I'm very tempted to propose we simply disable this profile by default:
I have very little hope at this point that we can make it open enough
to avoid breaking all kinds of corner cases, while keeping it strict
enough to be meaningful at all. Opinions?
Cheers,
--
intrigeri
uot;x" denied_mask="x" fsuid=1000 ouid=0
> Firefox is set as the preferred web browser under xfce "Preferred
> Applications".
Thanks for this bug report!
Could you please try reproducing this with thunderbird 1:52.4.0-2~exp1
or newer, currently available in Debian experimental?
Cheers,
--
intrigeri
Control: reassign -1 thunderbird
Control: fixed -1 1:52.4.0-2~exp1
Hi,
Ben Caradoc-Davies:
> opening a text attachment in thunderbird under xfce results in an error
> dialog:
> Failed to execute default File Manager.
> Failed to execute child process “/usr/bin/Thunar” (Permission denied).
Than
/anonscm.debian.org/cgit/pkg-mozilla/thunderbird.git/tree/debian/apparmor/usr.bin.thunderbird
Reassigning accordingly.
Note that the fix is already in Debian experimental :)
Cheers,
--
intrigeri
g the fix (once merged
upstream) into the Debian packaging, in your opinion?
Cheers,
--
intrigeri
801 - 900 of 3762 matches
Mail list logo
