m
Iain found.)
Cheers,
--
intrigeri
gtk2 to Qt5, and from twisted to
requests/socks.
If my team-mates disagree and want to give it a try anyway, fine.
Then, I would strongly recommend disabling the AppArmor profiles in
Buster by default.
Cheers!
--
intrigeri
t. reading the
blockresize's documentation before using it and wrt. having proper
backups, which makes the "causes serious data loss" justification
disputable IMHO.
Cheers,
--
intrigeri
Control: tag -1 + unreproducible
Hi Craig,
did this problem happen again? If it ever does, please share the
output of "sudo journalctl -u libvirtd.service" and the relevant
file timestamps.
I'm using libvirt + AppArmor heavily and have never seen it myself :/
Cheers,
--
intrigeri
018-06-02 01:28:10.0 +0300
> @@ -36,6 +36,7 @@
> network inet6 dgram,
> network packet dgram,
> network packet raw,
> + network netlink raw,
I've fixed this upstream with commit 3b1d19e6c9500d392b6635de92877b725d214f7f,
that was first released in libvirt v3.10.0.
Cheers,
--
intrigeri
output of the aa-status command
Also, does this affect all your VMs or only one?
Cheers,
--
intrigeri
install: 'internal error: cannot load AppArmor profile
>> 'libvirt-xxx--'
Can you still reproduce this problem on current Buster?
Worst case, on current Stretch?
Cheers,
--
intrigeri
Control: severity -1 important
Control: tag -1 + fixed-upstream
Hi,
bumping severity as this totally breaks an option offered to users via
virt-manager.
Now, I've verified that virt-manager in current sid still creates new
VMs with QXL graphics by default, so this bug only affects users who
opt
Jamie Strandboge:
> Thanks for considering the patch.
LGTM!
I'll apply this once Buster is released.
Hi,
Pierre-Elliott Bécue:
> This bugreport raises an interesting question regarding the tradeoff
> between the solution we implemented to fix bug #916639.
> Cc-ing intrigeri: I'm reconsidering the /etc/lxc/default.conf setting
> regarding apparmor.profile. Putting generated breaks
Paolo Greppi:
> Should this be documented in /usr/share/doc/apparmor/README.Debian ?
FWIW, this is now mentioned in the manpage that documents the policy
language: apparmor.d(5)
Cheers,
--
intrigeri
Source: apparmor
Version: 2.13.2-9
Severity: normal
Ubuntu folks have merged 2.13.2-9 and did quite a few packaging
improvements on top. Nothing seems to warrant a freeze exception but
once Buster is out, we should take a closer look at these changes
and merge.
a Live environment, so I think that'll be good enough; and if it's
not good enough, worst case we can patch the Live builds configuration
to disable the AppArmor LSM entirely, by passing apparmor=0 on the
kernel command line.
Cheers,
--
intrigeri
s to my list for the Paris BSP next week-end :)
Cheers,
--
intrigeri
ot Buster once it's released)
- one has not disabled automatic installation of Recommends
Cheers,
--
intrigeri
a closer look :)
> I'm too late on this for buster, but I think the smbd and nmbd
> profiles can be enabled by default in bullseye.
Great! Feel free to file a bug about it, ideally with a testing
report.
Cheers,
--
intrigeri
remove it from sid. Thanks in advance!
For more background info, see https://bugs.debian.org/894196
Cheers,
--
intrigeri
rmor-profiles: the label on the box explains why and should
hopefully discourage the vast majority of users to install it)
- Thunderbird
- some of the LibreOffice profiles
Thanks again!
Cheers,
--
intrigeri
orted on Debian yet:
Network Rules
DBus rules
Unix socket rules
Cheers,
--
intrigeri
notes/merge_requests/6
Funny race condition: I've just filed #924450. See you there :)
Cheers,
--
intrigeri
Actually Jonas (Cc'ed) already submitted something:
https://salsa.debian.org/ddp-team/release-notes/merge_requests/6
Thanks a lot!
Package: apparmor
Version: 2.13.2-9
Severity: important
… and submit via a MR against
https://salsa.debian.org/ddp-team/release-notes/ (in the "en"
directory).
.0.0.0]/104 [::1]/128
postfix/dynamicmaps_conversion_warning:
postfix/recipient_delim: +
postfix/not_configured:
postfix/compat_conversion_warning: true
postfix/protocols: all
postfix/newaliases: false
--
intrigeri
>From 4d98d0aa5aeb4fbb9941a4239251edfb1537a0e9 Mon Sep 17 00:00:00 2001
Fr
Control: tag -1 + moreinfo
Hi,
intrigeri:
> I'll try to prepare a fix ASAP unless you tell me you're on it.
Well, I've failed to do that in time for the Buster freeze, too bad.
What's the actual impact of this bug? Any user-visible problem?
Makes other profiles useless under their threat mo
y of time to think
about it and experiment with various ideas for Bullseye :)
Cheers,
--
intrigeri
Hi Paul & others,
Paul Gevers:
> I have decided to accept this regression to migrate to buster for
> apparmor to migrate to buster. Targeted fixes to fix the squid
> autopkgtest can be reason for an unblock.
This makes sense to me. Thanks for caring!
Cheers,
--
intrigeri
tion in a relaxed manner
instead of under a super-tight schedule, aiming at finding a great
solution for Bullseye (Debian 11), ideally under /var.
[1] https://xkcd.com/927/
Cheers,
--
intrigeri
Mathieu Parent:
>> test -d "/etc/apparmor.d/autogenerated" || silentexit "directory for
>> autogenerated profile sniplets doesn't exist"
> I prefer testing the parent directory.
BTW: s/sniplet/snippet/ I think :)
Cheers,
--
intrigeri
> After latest upgrade I've discovered via `aa-status` that new named profile
> `nvidia_modrpobe` is loaded in complain mode:
Good catch!
That's because debian/rules does this:
# set all profiles in apparmor-profiles to complain mode
cd $(CURDIR)/debian/tmp && sh
no such profile at all.
If I got it right, on Debian we don't ship
/etc/apparmor.d/usr.sbin.squid, so none of the tests in the
test_zz_apparmor function are meaningful in this context.
So I think this entire test case should be skipped on Debian.
Cheers,
--
intrigeri
Mathieu Parent:
> Thanks intrigeri for providing a solution!
Uploaded in apparmor 2.13.2-8, by the way.
It would be great if you could test if it works for you.
> I'm OK with this path and understand your rationale. However, I try to
> avoid distribution divergence.
Sure. Happy we'r
intrigeri:
> So I'll add this:
>#include if exists /etc/apparmor.d/samba/smbd-shares
I mean:
#include if exists
the file).
In a Debian context, a file that's automatically generated at runtime
should probably not be owned *in the dpkg sense* by any package.
But for sure, one package must be responsible for that file, and
remove it when the package is purged, and we can thus call it
the owner.
Cheers,
--
intrigeri
container-default-cgns" name="/" pid=13833 comm="(fwupd)"
> flags="rw, rslave"
This looks like https://bugs.debian.org/916639, which was fixed
in lxc 1:3.1.0+really3.0.3-3.
Cheers,
--
intrigeri
n
apparmor_parser -r -T -W "$APP_PROFILE" || true
fi
This is clearly not ideal, because depending on package configuration
ordering, some profiles may be loaded and some might not be.
I've not thought much about this problem yet, but I suspect that for
service packages such as LXC, handling this sort of things at the
systemd unit level might give us more robust ordering than what we're
currently doing via postinst. Food for thought :)
Cheers,
--
intrigeri
should run unconfined, i.e. rollback to how things
were by default on Stretch, so perhaps that's good enough?
Cheers!
--
intrigeri
Hi,
these settings are now in /etc/lxc/default.conf (as of lxc
1:3.1.0+really3.0.3-3) so depending on how debci sets things up, you
might actually not have to do anything once you update the hosts
to Buster.
Cheers,
--
intrigeri
already but I'm
not familiar with LXC and I don't know if they'll apply to
pre-existing containers.)
Thanks in advance!
Also, I'm setting severity to non-RC as it would be unfortunate to
block the migration to testing of… the very version that likely fixes
this bug. Once it's clarified that this is #916639, I'll fix
the metadata.
Cheers,
--
intrigeri
Hi Simon,
intrigeri:
> I will now deploy a modified version of ikiwiki, that includes your
> patch, on our production website, which will give it exposure to more
> realistic usage. I'll report back in 7-10 days, which hopefully should
> leave sufficient time for getting the fix in B
Control: fixed -1 1.2.0-1
Hi,
I think this bug is moot given the irssi-plugin-otr binary package is
now built from src:irssi.
Cheers,
--
intrigeri
Hi,
this looks like a duplicate of #921276 so perhaps you can join
Antoine's efforts :)
Cheers!
execute' for nil:NilClass
# ./spec/functions/ensure_packages_spec.rb:4:in `block (2 levels) in '
Cheers,
--
intrigeri
and testing from intrigeri, who wrote
> the code that I'm deleting and hopefully has a better picture of why it was/is
> necessary.
(I've tried to reply on the upstream bug but the anonpush mechanism
seems to be broken and the CGI rejects my edit, on the grounds that
the blogspam
at got ported to GTK+ 3 somewhat recently
is openpgp-applet, its Git history might be a useful source
of inspiration.
Happy hacking!
Cheers,
--
intrigeri
Control: tag -1 + moreinfo
> After recent updates on Sid, multiple GUI applications (like
> Thunderbird, Firefox, qTox) on KDE are hit by these kind of denies:
> ```
> type=AVC msg=audit(1548784946.545:1896): apparmor="DENIED"
> operation="open" profile="thunderbird"
>
gregor herrmann:
> On Mon, 28 Jan 2019 16:23:59 +0100, Jakub Wilk wrote:
>> Yes, it does. Thanks!
> Confirmed as well, thanks.
Thank you both!
Josh Triplett:
> I've submitted a debian-policy patch to document it.
Amazing! :)
t of /etc/" (#883584). Now that we've moved the
cache to /var/cache, I agree we can stop shipping CACHEDIR.TAG in the
apparmor package.
Marco, do you have anything to add on this topic before I go ahead?
Cheers,
--
intrigeri
.org/apparmor-team/apparmor/commit/0d642c21828a0c4eb51a70b058c3ebb695a770a4
… and report back whether it fixes the problem for you?
Thanks in advance!
Cheers,
--
intrigeri
Hi Bernhard, AppArmor folks and bystanders,
intrigeri:
> All this is doable but requires quite more work (and risks) than
> I thought initially.
> I'm starting to think that it would be vastly easier to do that via
> autopkgtests: […]
It's unfortunately too late to get all this
"moreinfo" as you've acknowledged that these patches need
updates as per Jamie's feedback.)
Cheers,
--
intrigeri
ob/master/profiles/apparmor.d/abstractions/audio
Cheers,
--
intrigeri
com/apparmor/apparmor/blob/master/profiles/apparmor.d/abstractions/audio
Cheers,
--
intrigeri
Hi,
intrigeri:
> Helmut Grohne:
>> I've concluded that regardless of whether this is a bug in gcc, it is a
>> bug in libapparmor-dev. I think that putting static and dynamic
>> libraries in different directories is a recipe for breakage. You really
>> should put
Hi,
Daniel Kahn Gillmor:
> On Sun 2018-10-07 10:31:13 +0200, intrigeri wrote:
>> intrigeri:
>>> What matters to me is the users' perspective. I think we should
>>> provide a clear, unambiguous transition path and avoid leaking
>>> technical details to users.
Hi,
Jonas Meurer:
> I'll see whether I find time during the next days to work out something
> for option a, but I have my doubts that we'll make it in time for Buster.
Thanks a lot for your work on this!
I'll reply on #910493.
Cheers,
--
intrigeri
l, if these rules work for you, I think the main
issue is about the possible security boundary violations.
Cheers,
--
intrigeri
the web interface, and then by Debian
convention /etc/cups is world-readable. But perhaps one of these could
change, e.g. does /etc/cups really have to be world-readable?
Cheers,
--
intrigeri
Control: severity -1 minor
Control: tag -1 + upstream
Control: forcemerge -1 918548
Rationale for the metadata changes:
- This bug is about a given proposed solution to a broad class
of problems.
- Bumping severity to minor, as the lack of a solution to this
problem may lead to
q=%40%7BXDG_
[3]
https://codesearch.debian.net/search?q=abstractions%2Fuser-%28download%7Cwrite%29
Cheers,
--
intrigeri
ortable with this option
so close to the freeze. I can live with option (A) too, and worst
case, well, with the fallback option if that's how it is.
Cheers,
--
intrigeri
Vincas Dargis:
> I'm sorry, but relevant update is in flight:
> https://gitlab.com/apparmor/apparmor/merge_requests/314
> mesa abstraction selection was incorrect decision.
OK. Merged upstream and cherry-picked into the packaging repo locally.
Will be part of next upload, presumably today! :)
Some features are not supported on Debian yet:
- Network Rules
- DBus rules
- Unix socket rules
… and I would hope I did check back then, so I *think* fine-grained
ptrace rules are enforced by Linux 4.19 mainline. Now, that's easy to
test :)
Cheers,
--
intrigeri
file or is this something
> that is not supported?
Indeed, unionfs in general are pretty poorly supported by AppArmor at
the moment. Adding the attach_disconnected flag, as suggested by
Vincas, often helps, but it's not always sufficient.
To make AppArmor work with aufs, in Tails we need quite a few custom
tricks; and overlayfs will need yet another set of tricks.
Cheers,
--
intrigeri
age :)
Cheers,
--
intrigeri
ups dir
I was not able to find any reference to the "trap profile" idea
in our documentation. Could you please point me in the right
direction? Thanks in advance!
Cheers,
--
intrigeri
if the impact is "without
access to /usr/share/drirc.d/00-mesa-defaults.conf, apps are seriously
broken", then it could be a candidate.
Cheers,
--
intrigeri
lusions
make sense to me; they also match what I see other packages do.
I've applied your patch locally and will upload in the next couple
days unless testing displays issues.
Cheers,
--
intrigeri
ts before doing anything else, and exit
silently if it doesn't? That's for example what most of the scripts
I see in my /etc/cron.daily/ do.
The beginning of the script would then look like:
set -e
[ -n /usr/bin/cert-sync ] || exit 0
echo "Updating Mono key store"
Cheers,
--
intrigeri
intrigeri:
> Michael Biebl:
>> Please let us know about the results of those tests.
> Will do!
All green from the perspective of Tails' integration test suite :)
I'll let you know if the reviewer for this Tails proposed change (most
likely lamby) finds issues relevant to Debian.
Hi Michael!
Thanks for the quick answer.
Michael Biebl:
> Am 13.01.19 um 10:46 schrieb intrigeri:
>> What's your plan wrt. stretch-backports?
> I do think we nailed the worst regressions by now, so my plan was to
> wait until 240-4 has migrated to testing and then upload th
backported
patch upstream. Or the Debian LXC maintainers "just" (sic) apply my
3 backported patches. Or we disable AppArmor support for LXC in Buster
(not a regression vs. Stretch but pretty sad).
Cheers!
--
intrigeri
kported these patches and proposed them here,
see my initial message on this bug report :)
Cheers,
--
intrigeri
on the systemd package!
Cheers,
--
intrigeri
in advance!
Cheers,
--
intrigeri
>From 3620e22ca427333ee063a594d960ab365bfce92d Mon Sep 17 00:00:00 2001
From: intrigeri
Date: Sat, 12 Jan 2019 07:10:24 +
Subject: [PATCH] Remove myself from Uploaders.
---
debian/control | 1 -
1 file changed, 1 deletion(-)
diff --git a/debian/control b/deb
Hi,
Chris Lamb:
>> It seems more recent. What do I miss with the one you mentioned? That
>> seems untouched for more than a year.
> Hm, I'm not sure now (!). Lynxis/intrigeri, can you comment? Marking this
> bug as "moreinfo" for now.
I'm not directly involv
Hi,
Vincas Dargis:
> intrigeri what's your take on this? Where should new profiles be
> "placed"?
Having the policy live along with the software it confines, i.e.
in the upstream VCS, is ideal, as long as upstream somewhat cares
about it and the maintainer of said policy tracks
gregor herrmann:
> Sounds like a removal candidate?
Agreed ⇒ usertagged as such :)
init.d/apparmor: aa_log_action_end: not
> found
Reported separately as #917962. I'll handle it but with lower priority
than this very bug report, since the consequences are much less important.
Cheers,
--
intrigeri
Package: apparmor
Version: 2.13.2-2
Severity: normal
Since 2.13.2-2 the initscript uses the upstream rc.apparmor.functions
shell library, which expects its consumer to implement a bunch of
logging functions. As reported initially on
https://bugs.debian.org/917874#11, our initscript does not
/bugreport.cgi?bug=878193;msg=7)
So I don't understand why this bug should be RC for Buster: it does
not actually affect Buster and there's no supported upgrade path given
PuppetDB was not part of any Debian stable release yet.
Adrian, what do you think? Thanks in advance!
Cheers,
--
intrigeri
h the AppArmor-related bugs, probably
in a few weeks or so.
Cheers,
--
intrigeri
s
> Manager
> Dec 16 15:04:36 caronte systemd[1]: Started The PHP 7.0 FastCGI Process
> Manager.
I don't understand what's the problem here.
Cheers,
--
intrigeri
bug's metadata accordingly :)
Cheers,
--
intrigeri
intrigeri:
> My initial draft seems to be working fine at first glance:
Updated my already outdated upstream MR (merge conflicts: my MR
prompted other upstream folks to take a look at the affected file… and
themselves submit a bunch of other MRs to remove obsolete bits :)
+ pinged those I'd l
original request ("provide a way to opt out of
AppArmor confinement when running tests"). The 2 bug reports I've
filed today are on our radar via usertags already.
Cheers,
--
intrigeri
Hi,
intrigeri:
> Ivan Sergio Borgonovo:
>> As you said probably apparmor seems not to be the culprit.
>> Nov 04 20:21:13 kerberos audit[1280]: AVC apparmor="DENIED"
>> operation="mount" info="failed type match" error=-13
>> profile=
> 1. Ask the src:lxc maintainers to apply these 3 upstream patches
>until they upgrade the package to 3.1.0+.
#916639
> 2. Ask the debci maintainers to use the config described above
>for LXC containers used to run autopkgtests, once they upgrade
>to Buster.
#916644
with the patches I've provided
on #916639.
Context: https://bugs.debian.org/911806
Cheers,
--
intrigeri
of LXC 3.1.0+ :)
Cheers,
--
intrigeri
From: Wolfgang Bumiller
Date: Wed, 25 Jul 2018 12:11:31 +0200
Subject: apparmor: profile generation
This copies lxd's apparmor profile generation. This tries to
detect features such as cgroup namespaces, apparmor
namespaces and stacking support, and has
ontainers used to run autopkgtests, once they upgrade
to Buster.
3. Let you decide what to do with the request this bug report was
originally about.
> Hope this helpful.
This was *very* helpful and saved me lots of time :)
Thanks for your patience,
cheers,
--
intrigeri
>From 035ef2dcad71f4498
e class of problems fixed in 2.11.1-4 have also been
fixed in a Stretch p-u a while ago, so I *think* that a backport of
lxc to Stretch should not be affected. I did not test this though.
Cheers,
--
intrigeri
Control: severity -1 minor
Vincas Dargis:
> On 9/19/18 8:10 PM, intrigeri wrote:
>>> It appears that Thunderbird now needs access to /etc/ld.so.conf on
>>> Stretch, while AppArmor profile does not allow that:
>>
>> What's the practical effect of this denial,
e, I (or one of the attendees to one of the many
upcoming BSPs) will gladly fix this with a NMU.
Cheers,
--
intrigeri
and maybe shed some light upon what
options we have here, both short and long term?
Cheers,
--
intrigeri
ntainer judge whether this should be enabled
by default.
Other than this, it would be good if the "Usually this is needed only
for debugging" documentation string was updated a little bit to
reflect common current use cases of ptrace.
Cheers,
--
intrigeri
Control: fixed -1 1.3-1
Ulrike Uhlig:
> This is fixed in the current version of Onionshare (> 1.3).
Cool! I'm letting the BTS know about it then :)
Hi Sean,
Sean Whitton:
> Here is a patch. Please let me know the results of any testing you're
> able to do.
I'm running 1.2-1 on sid. I did not test the exact UX failure mode
this bug report is about but I confirm that a similar problem is now
fixed. When there's a name resolution failure,
queue somewhere under /home/brian/tmp/.
Now, if documentation we're shipping has lead you to create this queue
in /home/brian/capture, please file a dedicated bug about it and I'll
try to fix it.
> (I hope the User* control fields are correct).
They are, thank you! :)
Cheers,
--
intrigeri
tls protect
Debian users against exploitation, so I find RC severity hard to
justify given this only affects users who manually pass --debug under
a non-default sysctl/kernel configuration.
In any case, this should be fixed :)
Cheers,
--
intrigeri
401 - 500 of 3755 matches
Mail list logo
