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 so
in 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:30:2
h 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
uld 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
tream last July:
https://gitlab.com/apparmor/apparmor/commit/ff66ca90390d14fa710ac28cc20728f934152724
… which will reach Debian once I package the recent 2.12 upstream release.
Cheers,
--
intrigeri
for your feedback.
I believe I've fixed this 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
agree 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:
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
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
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
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 <intrig...@debian.org>
Commit ID: f2cc06d6696a35288f109681d57fd313b6334627
Commit URL:
https://anonscm.debian.org/cgit/reportbug/reportbug.git;a=commitdiff;h=f2cc06d6696a35288f109681d57fd313b6334627
Pat
ow 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
, 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 operation
70808
> 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 <intrig...@debian.org> 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 :-)
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
>> ob
Martin:
> I can confirm that the changes from commit
>> https://gitlab.com/apparmor/apparmor/commit/cc5a23d4c1236a0221f7bae0fd3d59f583ec9a1d
> fix the problem.
Thanks!
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 :)
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
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 so o
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
>>> majori
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 <intrig...@boum.org>
Date: Thu, 7 Dec 2017 17:
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
tablished 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
l path?)
If the above does not work, yes.
> One could also just patch it :-)
Absolutely.
Cheers,
--
intrigeri
n 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
.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
MEDIRS}+=/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.
:)
d 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 re
t one must
be in the "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
ful 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
nt,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
f 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
>> >> of parser.conf somehow. A
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 release tea
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
>> >
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'll of course def
than 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
ent, 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
ks 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 :)
thunderbird /usr/lib/thunderbird/thunderbird {
+profile thunderbird /usr/lib/thunderbird/thunderbird{,-bin} {
#include
#include
#include
Cheers,
--
intrigeri
jority 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
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
/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
directly edit it so it looks like this:
/usr/bin/irssi flags=(complain) {
Cheers,
--
intrigeri
e :)
Cheers,
--
intrigeri
y 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
in recent kernels.
+
+ -- intrigeri <intrig...@debian.org> 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
--- apparmor-
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 :)
I've rebased m
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-882672-v2 after you've merg
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 it'll
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:
>
Control: severity -1 minor
Once AppArmor profile for Thunderbird is disabled by default
(#882672), this bug will only affect users who opt-in.
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
ide whether it's good enough or we should ship
this profile disabled by default.
Cheers,
--
intrigeri
void 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).
/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
Hi!
Vincas Dargis:
> I have discovered this DENIED message on Debian Sid with Thundebird:
> type=AVC msg=audit(1511012066.035:570): apparmor="DENIED" operation="open"
> profile="thunderbird"
> name="/etc/pulse/client.conf.d/00-disable-autospawn.conf"
> pid=4507 comm="thunderbird"
requested_mask="c"
denied_mask="c" fsuid=1002 ouid=1002
Nov 21 18:45:11 ensifera kernel: audit: type=1400 audit(1511286311.333:1879):
apparmor="DENIED" operation="open" profile="/usr/bin/obfsproxy"
name="/proc/6975/mounts" pid=6975 comm="obfsproxy" requested_mask="r"
denied_mask="r" fsuid=1002 ouid=1002
I could not see the error Marc is reporting, because I don't know how
exactly I should run obfsproxy to trigger it. Marc, could you please
share the exact command line you're running?
Lunar, unless you disagree I'll do a team upload that disables this
profile by default. We can re-enable it if/once someone feels like
keeping it up-to-date and working. What do you think?
Cheers,
--
intrigeri
Sascha Steinbiss:
> Can anyone else in the team reproduce this issue or probably comment?
I can't reproduce this on current sid.
make sense if you would
send your proposed changes directly upstream :)
Cheers,
--
intrigeri
the next upload of Thunderbird to sid
so I went ahead and submitted a MR upstream:
https://gitlab.com/apparmor/apparmor-profiles/merge_requests/4
Simon, can you please review it and report back there?
Cheers,
--
intrigeri
n my
> part),
> although if feature set pining is working fine on 4.14, we have still have
> some time,
> I guess..?
Yes :)
Cheers,
--
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'l
it 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
801 - 900 of 3753 matches
Mail list logo