Bug#826218: [pkg-apparmor] Bug#826218: Bug#826218: Bug#826218: Bug#826218: Complain still interferes
Jamie Strandboge: > apparmor_parser -r ... actually allows to replace the profile for a running > process. [...] Thanks for the explanation! > The man page is not at all clear on this point and that is a bug in > the man page. I've reported it as https://bugs.launchpad.net/apparmor/+bug/1608075 Cheers, -- intrigeri
Bug#826218: [pkg-apparmor] Bug#826218: Bug#826218: Bug#826218: Complain still interferes
On Sat, 2016-07-30 at 14:28 +0200, intrigeri wrote: > Hi, > > Guido Günther: > > > > so how can I find out why the access is still blocked although I added > > an explicit allow line? I kind of suspect that reloading the profile > > does not work but have nothing that supports this (reloading without > > cache, and in verbose mode all look good). > apparmor(7) reads: > > Profiles are applied to a process at exec(3) time (as seen through the > execve(2) system call); an already running process cannot be confined. > However, once a profile is loaded for a program, that program will be > confined on the next exec(3). > > The way I understand it, this implies that a modified+reloaded profile > will only be applied to the confined program next time it is executed. > apparmor_parser -r ... actually allows to replace the profile for a running process. The trick is that the process needs to be running under a profile first before the profile can be replaced. Put another way-- if a program is launched unconfined, then you may not come later and confine it. If a program is launched under a profile (even if it is super strict or lenient), you can replace that profile and have it apply to the running process. The man page is not at all clear on this point and that is a bug in the man page. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part
Bug#826218: [pkg-apparmor] Bug#826218: Bug#826218: Complain still interferes
Hi, Guido Günther: > so how can I find out why the access is still blocked although I added > an explicit allow line? I kind of suspect that reloading the profile > does not work but have nothing that supports this (reloading without > cache, and in verbose mode all look good). apparmor(7) reads: Profiles are applied to a process at exec(3) time (as seen through the execve(2) system call); an already running process cannot be confined. However, once a profile is loaded for a program, that program will be confined on the next exec(3). The way I understand it, this implies that a modified+reloaded profile will only be applied to the confined program next time it is executed. Cheers, -- intrigeri
Bug#826218: [pkg-apparmor] Bug#826218: Bug#826218: Complain still interferes
Hi,
On Mon, Jun 06, 2016 at 01:21:36AM -0700, John Johansen wrote:
> On 06/05/2016 11:22 PM, Guido Günther wrote:
> > Hi Christian,
> >
> > Thanks a lot for your comments!
> >
> > On Mon, Jun 06, 2016 at 01:14:08AM +0200, Christian Boltz wrote:
> > [..snip..]
> >> You can enable the logging by adding the audit keyword, but the general
> >> rule is not to log anything that is already handled (allowed or denied)
> >> in the profile.
> >>
> >>> * a way to audit calls to subprocesses indicating whether the
> >>> environment was scrubbed or not
> >>
> >> You'll get this information by reading the profile ;-) It already had
> >> "/usr/sbin/* PUx" [1] which also allowed /usr/sbin/virtlogd - but with
> >> environment scrubbing.
> >
> > The rule tells me what the profile is supposed to do, not what it is
> > doing. Ideally I'd like to debug this without modifying any rules.
> >
> > It's like the difference between reading code and debugging code. With a
> > debugger I can see what the program is doing while the code tells me
> > what it is supposed to do.
> >
>
> Another mode that might be helpful is forcing audit mode. This can be done
> in two ways, to apply it globally
>
> echo -n all > /sys/module/apparmor/parameters/audit
>
> or by setting the mode on the profile
>
> profile foo flags=(audit) { ... }
>
>
> this will audit a message for every rule that apparmor allows. This can
> be extremely noisy even just doing it for a single profile, so I would not
> use the global option.
>
> You will likely also have to turn off rate limiting by doing
>
> echo 0 > /proc/sys/kernel/printk_ratelimit
>
> even then the kernel ring buffer may overflow and you might lose messages.
I'm stuck again debugging an apparmor issue so maybe somebody has some
pointers (which I'll gladly add to the weeky again). I'm looking into:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805002
where hotplugging a disk with libvirt fails iff apparmor is enabled.
I can reproduce this and to get virt-aa-helper and libvirtd out of the
game I came up with:
echo "/var/lib/libvirt/images/powerpc.img rw," >>
/etc/apparmor.d/libvirt/libvirt-a9287b6e-ca06-42fe-b1a2-06830752843a.files
chmod u+rw /var/lib/libvirt/images/powerpc.img
chown libvirt-qemu: /var/lib/libvirt/images/powerpc.img
/sbin/apparmor_parser -r
/etc/apparmor.d/libvirt/libvirt-a9287b6e-ca06-42fe-b1a2-06830752843a
virsh qemu-monitor-command wheezy --pretty --cmd
'{"execute":"human-monitor-command","arguments":{"command-line":"drive_add
dummy
file=/var/lib/libvirt/images/powerpc.img,format=raw,if=none,id=drive-virtio-disk1"}}'
which does the same as "virsh attach-disk domain
/var/lib/libvirt/images/powerpc.img".
So we allow access to a file (via apparmor and unix perms), reload the
profile and tell qemu to attach the disk but I this in the logs after
issuing the last command:
[ 2585.155440] audit: type=1400 audit(1469130399.200:271): apparmor="DENIED"
operation="open" profile="libvirt-a9287b6e-ca06-42fe-b1a2-06830752843a"
name="/var/lib/libvirt/images/powerpc.img" pid=4202 comm="qemu-system-x86"
requested_mask="r" denied_mask="r" fsuid=117 ouid=117
[ 2585.155472] audit: type=1400 audit(1469130399.200:272): apparmor="AUDIT"
operation="getattr" profile="libvirt-a9287b6e-ca06-42fe-b1a2-06830752843a"
name="/var/lib/libvirt/images/powerpc.img" pid=4202 comm="qemu-system-x86"
requested_mask="r" fsuid=117 ouid=117
[ 2585.155547] audit: type=1400 audit(1469130399.200:273): apparmor="DENIED"
operation="open" profile="libvirt-a9287b6e-ca06-42fe-b1a2-06830752843a"
name="/var/lib/libvirt/images/powerpc.img" pid=4202 comm="qemu-system-x86"
requested_mask="rw" denied_mask="rw" fsuid=117 ouid=117
so how can I find out why the access is still blocked although I added
an explicit allow line? I kind of suspect that reloading the profile
does not work but have nothing that supports this (reloading without
cache, and in verbose mode all look good).
Cheers
-- Guido
Bug#826218: Complain still interferes
Control: retitle -1 Better document complain mode and debugging process Control: severity -1 normal Hi, Guido Günther wrote (07 Jun 2016 05:58:56 GMT) : > On Mon, Jun 06, 2016 at 12:47:08PM +0200, intrigeri wrote: >> Guido, what do you think we should do about this >> bug report now? Downgrade to normal severity and retitle to track >> upstream progress of the planned improvements, perhaps? > I'm all for downgrading and retitling. Done! > The information provided by upstream > (thanks for that!) is too valuable to let it go to the bts archive > as of yet. ACK. > I wouldn't have filed a bug if: > * The manpage would have mentioned that deny rules are still enforced > (and don't print anything) in the aa-complain manpage. Christian > added a note on this at > > https://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/3482?start_revid=3482 > * The manpage would have redirected me to a page that lists the other > nice commands mentioned by John > This informaton should IMHO go into upstream manpages / documentation > and be linked to from the various manpages one steps on first > (aa-complain, ...) in order to hopefully help people along to debug > things. > For the time being I dumpted things here: > https://honk.sigxcpu.org/piki/development/apparmor-debugging/ u. volunteered to work on this \o/ Cheers, -- intrigeri
Bug#826218: Complain still interferes
Hi, On Mon, Jun 06, 2016 at 12:47:08PM +0200, intrigeri wrote: > Control: tag -1 + upstream > Control: tag -1 - moreinfo > > Hi, > > Guido Günther wrote (06 Jun 2016 06:33:45 GMT) : > > It's "good enough" for debugging on a test system. > > Incredibly helpful, thanks! > > Thanks upstream folks for helping :) I'm also glad that the root cause > of the problem was identified and a patch submitted to > upstream libvirt. > > My understanding is that the required debugging features are either > already there (though hard to find), or planned for implementation in > upstream AppArmor. Guido, what do you think we should do about this > bug report now? Downgrade to normal severity and retitle to track > upstream progress of the planned improvements, perhaps? Or just close > because it's actually "good enough" as-is? I'm all for downgrading and retitling. The information provided by upstream (thanks for that!) is too valuable to let it go to the bts archive as of yet. I wouldn't have filed a bug if: * The manpage would have mentioned that deny rules are still enforced (and don't print anything) in the aa-complain manpage. Christian added a note on this at https://bazaar.launchpad.net/~apparmor-dev/apparmor/master/revision/3482?start_revid=3482 * The manpage would have redirected me to a page that lists the other nice commands mentioned by John This informaton should IMHO go into upstream manpages / documentation and be linked to from the various manpages one steps on first (aa-complain, ...) in order to hopefully help people along to debug things. For the time being I dumpted things here: https://honk.sigxcpu.org/piki/development/apparmor-debugging/ Cheers, -- Guido
Bug#826218: Complain still interferes
Control: tag -1 + upstream Control: tag -1 - moreinfo Hi, Guido Günther wrote (06 Jun 2016 06:33:45 GMT) : > It's "good enough" for debugging on a test system. > Incredibly helpful, thanks! Thanks upstream folks for helping :) I'm also glad that the root cause of the problem was identified and a patch submitted to upstream libvirt. My understanding is that the required debugging features are either already there (though hard to find), or planned for implementation in upstream AppArmor. Guido, what do you think we should do about this bug report now? Downgrade to normal severity and retitle to track upstream progress of the planned improvements, perhaps? Or just close because it's actually "good enough" as-is? Cheers, -- intrigeri
Bug#826218: [pkg-apparmor] Bug#826218: Bug#826218: Complain still interferes
On 06/05/2016 11:22 PM, Guido Günther wrote:
> Hi Christian,
>
> Thanks a lot for your comments!
>
> On Mon, Jun 06, 2016 at 01:14:08AM +0200, Christian Boltz wrote:
> [..snip..]
>> You can enable the logging by adding the audit keyword, but the general
>> rule is not to log anything that is already handled (allowed or denied)
>> in the profile.
>>
>>> * a way to audit calls to subprocesses indicating whether the
>>> environment was scrubbed or not
>>
>> You'll get this information by reading the profile ;-) It already had
>> "/usr/sbin/* PUx" [1] which also allowed /usr/sbin/virtlogd - but with
>> environment scrubbing.
>
> The rule tells me what the profile is supposed to do, not what it is
> doing. Ideally I'd like to debug this without modifying any rules.
>
> It's like the difference between reading code and debugging code. With a
> debugger I can see what the program is doing while the code tells me
> what it is supposed to do.
>
Another mode that might be helpful is forcing audit mode. This can be done
in two ways, to apply it globally
echo -n all > /sys/module/apparmor/parameters/audit
or by setting the mode on the profile
profile foo flags=(audit) { ... }
this will audit a message for every rule that apparmor allows. This can
be extremely noisy even just doing it for a single profile, so I would not
use the global option.
You will likely also have to turn off rate limiting by doing
echo 0 > /proc/sys/kernel/printk_ratelimit
even then the kernel ring buffer may overflow and you might lose messages.
Ideally I would like to add a full debug mode back in to apparmor, but
it was so noisy and lossy in the past that it was almost useless. It
got ripped out in the cleanup/rewrite and will resurface when we can
better control it. We do have some ideas, like being able to specify
a set of rules to trigger events (audit, or signal on). A signal to stop
tasks so a debugger can have a chance to introspect and catch up on
the debug stream etc. Not that that helps you as it is not available
yet.
Bug#826218: [pkg-apparmor] Bug#826218: Bug#826218: Complain still interferes
On Sun, Jun 05, 2016 at 06:51:18PM -0700, John Johansen wrote: [..snip..] > With that said if you turn of debug mode apparmor will log a few extra > messages to dmesg (not via the audit subsystem). This will let you see > when environment scrubbing has been applied. > > echo 1 > /sys/module/apparmor/parameters/debug > > Also not this isn't going to give you a flood of extra messages its just > for a few things like, env scrubbing, clearing unsafe personality bits, > no new privs etc. > > > @John: Do you have a different opinion on Guido's points? > > > > yeah we should be logging extra info. As for complain mode we aren't > changing its behavior but their will be a new mode that is closer to > what I think he wants. > > Also it is possible to turn off deny audit quieting by doing > > echo -n noquiet >/sys/module/apparmor/parameters/audit > > sadly this is global, not per profile It's "good enough" for debugging on a test system. Incredibly helpful, thanks! -- Guido
Bug#826218: [pkg-apparmor] Bug#826218: Bug#826218: Complain still interferes
Hi Christian, Thanks a lot for your comments! On Mon, Jun 06, 2016 at 01:14:08AM +0200, Christian Boltz wrote: [..snip..] > You can enable the logging by adding the audit keyword, but the general > rule is not to log anything that is already handled (allowed or denied) > in the profile. > > > * a way to audit calls to subprocesses indicating whether the > > environment was scrubbed or not > > You'll get this information by reading the profile ;-) It already had > "/usr/sbin/* PUx" [1] which also allowed /usr/sbin/virtlogd - but with > environment scrubbing. The rule tells me what the profile is supposed to do, not what it is doing. Ideally I'd like to debug this without modifying any rules. It's like the difference between reading code and debugging code. With a debugger I can see what the program is doing while the code tells me what it is supposed to do. > I'm CC'ing another upstream developer, but I wouldn't be surprised if he > tells you the same ;-) > > @John: Do you have a different opinion on Guido's points? > > > * other stuff I might not even know about yet like DBus denials … > > Actually I can't tell you too much about DBus because only the Ubuntu > kernel has DBus support for AppArmor (it's not upstreamed yet), and I'm > using openSUSE ;-) > > > Regards, > > Christian Boltz > > [1] I'm not sure if this rule (and the other broad PUx rules) are a good > idea [2], but a) I don't know libvirtd good enough to judge on it > and b) that's a totally different topic ;-) > > [2] These PUx rules allow to execute _all_ programs, and most of them > unconfined (except if a profile for this program exists). > I slightly ;-) doubt libvirtd needs to execute all of them... I totally aggree here! -- Guido
Bug#826218: [pkg-apparmor] Bug#826218: Bug#826218: Complain still interferes
On 06/05/2016 04:14 PM, Christian Boltz wrote: > Hello, > > Am Sonntag, 5. Juni 2016, 13:34:19 CEST schrieb Guido Günther: >> On Sat, Jun 04, 2016 at 06:38:46PM +0200, Christian Boltz wrote: >>> deny rules are enforced even if you switch the profile to complain >>> mode, and don't leave any log events behind. You might want to >>> change them to"audit deny" temporarily to get log events (with >>> AUDIT). >> >> I did not know. Thanks! IMHO this needs to be mentioned in the >> aa-complain manpage to fulfill the "no PhD in computer science needed >> for" promise. > > Good point. I just commited an updated manpage upstream (will be in > 2.11, 2.10.2 and 2.9.4 whenever they get released). > >> The issue turned out to be environment scrubbing: >> >> https://www.redhat.com/archives/libvir-list/2016-June/msg00117.html >> >> but I think the issue is still valid: getting an idea what gets >> dropped to the floor is too hard atm. With complain mode I'd exepct: >> >> * denials logged by default > > The whole point of deny rules is to silence the logging (except if they > also have the audit keyword). > > You can enable the logging by adding the audit keyword, but the general > rule is not to log anything that is already handled (allowed or denied) > in the profile. I will add that new versions of apparmor will be picking up a new mode that will not apply quieting for known denials. > >> * a way to audit calls to subprocesses indicating whether the >> environment was scrubbed or not > > You'll get this information by reading the profile ;-) It already had > "/usr/sbin/* PUx" [1] which also allowed /usr/sbin/virtlogd - but with > environment scrubbing. > > I'm CC'ing another upstream developer, but I wouldn't be surprised if he > tells you the same ;-) > So the logging of scrubbing is not where I would like at the moment. We do have work planned around improving environment variable handling so this hasn't been touched yet. With that said if you turn of debug mode apparmor will log a few extra messages to dmesg (not via the audit subsystem). This will let you see when environment scrubbing has been applied. echo 1 > /sys/module/apparmor/parameters/debug Also not this isn't going to give you a flood of extra messages its just for a few things like, env scrubbing, clearing unsafe personality bits, no new privs etc. > @John: Do you have a different opinion on Guido's points? > yeah we should be logging extra info. As for complain mode we aren't changing its behavior but their will be a new mode that is closer to what I think he wants. Also it is possible to turn off deny audit quieting by doing echo -n noquiet >/sys/module/apparmor/parameters/audit sadly this is global, not per profile >> * other stuff I might not even know about yet like DBus denials … > DBus denials are weird in that they are handled by an apparmor extension inside of the user space daemon which will use the audit subsystem if it can (system bus + audit subsystem is set up) but will fallback to regular syslog if it can't. So session bus and system bus can end up in different logs, and there are a few other oddities. There is some work that could be done to improve it but right now priorities are else where, and there is a hesitancy to put a lot more effort into it until the whole kdbus thing is more clear. > Actually I can't tell you too much about DBus because only the Ubuntu > kernel has DBus support for AppArmor (it's not upstreamed yet), and I'm > using openSUSE ;-) > right, sorry I still mean to get you experimental kernels in the build service. I have just been side tracked.
Bug#826218: [pkg-apparmor] Bug#826218: Bug#826218: Complain still interferes
Hello, Am Sonntag, 5. Juni 2016, 13:34:19 CEST schrieb Guido Günther: > On Sat, Jun 04, 2016 at 06:38:46PM +0200, Christian Boltz wrote: > > deny rules are enforced even if you switch the profile to complain > > mode, and don't leave any log events behind. You might want to > > change them to"audit deny" temporarily to get log events (with > > AUDIT). > > I did not know. Thanks! IMHO this needs to be mentioned in the > aa-complain manpage to fulfill the "no PhD in computer science needed > for" promise. Good point. I just commited an updated manpage upstream (will be in 2.11, 2.10.2 and 2.9.4 whenever they get released). > The issue turned out to be environment scrubbing: > > https://www.redhat.com/archives/libvir-list/2016-June/msg00117.html > > but I think the issue is still valid: getting an idea what gets > dropped to the floor is too hard atm. With complain mode I'd exepct: > > * denials logged by default The whole point of deny rules is to silence the logging (except if they also have the audit keyword). You can enable the logging by adding the audit keyword, but the general rule is not to log anything that is already handled (allowed or denied) in the profile. > * a way to audit calls to subprocesses indicating whether the > environment was scrubbed or not You'll get this information by reading the profile ;-) It already had "/usr/sbin/* PUx" [1] which also allowed /usr/sbin/virtlogd - but with environment scrubbing. I'm CC'ing another upstream developer, but I wouldn't be surprised if he tells you the same ;-) @John: Do you have a different opinion on Guido's points? > * other stuff I might not even know about yet like DBus denials … Actually I can't tell you too much about DBus because only the Ubuntu kernel has DBus support for AppArmor (it's not upstreamed yet), and I'm using openSUSE ;-) Regards, Christian Boltz [1] I'm not sure if this rule (and the other broad PUx rules) are a good idea [2], but a) I don't know libvirtd good enough to judge on it and b) that's a totally different topic ;-) [2] These PUx rules allow to execute _all_ programs, and most of them unconfined (except if a profile for this program exists). I slightly ;-) doubt libvirtd needs to execute all of them... -- [bugzilla is] being as co-operative as a 2 legged donkey pulling a 10 ton tractor under attack by an army of bees [Richard Brown in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#826218: [pkg-apparmor] Bug#826218: Complain still interferes
Hi Christian, On Sat, Jun 04, 2016 at 06:38:46PM +0200, Christian Boltz wrote: > Hello, > > Am Samstag, 4. Juni 2016, 15:04:04 CEST schrieb Guido Günther: > > Well, there are no DENIED messages - that's the puzzling part and the > > reason for this bug. The should be a all also contain "audit" and end > > up in dmesg so my grep expression should have caught them > > Does the profile contain any deny rules? > If unsure, run > apparmor_parser -pq /etc/apparmor.d/the.profile.to.check | grep deny > (this will print out the profile with all includes merged in) $ apparmor_parser -pq /etc/apparmor.d/usr.sbin.libvirtd | grep -i deny # deny ptrace (readby) ... # deny ptrace (tracedby) ... audit deny /sbin/apparmor_parser rwxl, audit deny /etc/apparmor.d/libvirt/** wxl, audit deny /sys/kernel/security/apparmor/features rwxl, audit deny /sys/kernel/security/apparmor/matching rwxl, audit deny /sys/kernel/security/apparmor/.* rwxl, > deny rules are enforced even if you switch the profile to complain mode, > and don't leave any log events behind. You might want to change them > to"audit deny" temporarily to get log events (with AUDIT). I did not know. Thanks! IMHO this needs to be mentioned in the aa-complain manpage to fulfill the "no PhD in computer science needed for" promise. > BTW: If you switch the profile to complain mode, the messages will > contain ALLOWED instead of DENIED. The issue turned out to be environment scrubbing: https://www.redhat.com/archives/libvir-list/2016-June/msg00117.html but I think the issue is still valid: getting an idea what gets dropped to the floor is too hard atm. With complain mode I'd exepct: * denials logged by default * a way to audit calls to subprocesses indicating whether the environment was scrubbed or not * other stuff I might not even know about yet like DBus denials … Otherwise it will be hard to scale out to Debian developers enabling (and fixing) profiles for their packages and that's IMHO the only way to get apparmor coverage. Cheers, -- Guido > -- > [AppArmor] Unlike SELinux, it does not require a PhD in computer > security to get it working... [Peter Czanik in opensuse-factory] …what about keepping it working?
Bug#826218: [pkg-apparmor] Bug#826218: Complain still interferes
Hello, Am Samstag, 4. Juni 2016, 15:04:04 CEST schrieb Guido Günther: > Well, there are no DENIED messages - that's the puzzling part and the > reason for this bug. The should be a all also contain "audit" and end > up in dmesg so my grep expression should have caught them Does the profile contain any deny rules? If unsure, run apparmor_parser -pq /etc/apparmor.d/the.profile.to.check | grep deny (this will print out the profile with all includes merged in) deny rules are enforced even if you switch the profile to complain mode, and don't leave any log events behind. You might want to change them to"audit deny" temporarily to get log events (with AUDIT). BTW: If you switch the profile to complain mode, the messages will contain ALLOWED instead of DENIED. Regards, Christian Boltz PS: random sig ;-) -- [AppArmor] Unlike SELinux, it does not require a PhD in computer security to get it working... [Peter Czanik in opensuse-factory] signature.asc Description: This is a digitally signed message part.
Bug#826218: Complain still interferes
Hi intrigeri,
On Sat, Jun 04, 2016 at 02:56:39PM +0200, intrigeri wrote:
[..snip..]
> >> To confirm this, we need:
> >>
> >> * the kernel / auditd logs from AppArmor, when the profile is in
> >>complain or enforce mode
>
> [... snipping logs about the parser load/etc. operations ...]
>
> Let me be more specific: I would like to see the log about what
> AppArmor blocks (the corresponding log entries should contain the
> "DENIED" string).
Well, there are no DENIED messages - that's the puzzling part and the
reason for this bug. The should be a all also contain "audit" and end up
in dmesg so my grep expression should have caught them (and I .
> >> * the generated profile (/etc/apparmor.d/libvirt/libvirt-${uuid}*)
>
> > As far as can tell there are no new files generaed with the uuid of the
> > sqs domain.
>
> Hmmm, OK. Here I have to admit that I have no clue how libvirt handles
> AppArmor with qemu:///session; I've never tried it myself, and I don't
> even know if it's supposed to be supported. Can you reproduce this
> problem with qemu:///system?
No, session works as expected. The start of this journay basically was
to find out what aa does to qemu:///ession (at the very best it
should totally ignore it).
> I guess that at some point I should simply try and run your
> autopkgtest myself to investigate, but first if you don't mind I'd
> like a little bit more input from you, until we can be certain whether
> it's a bug in AppArmor or in libvirt's AppArmor integration.
> Fair enough?
Sure. I'm happy to provide more input.
Cheers,
-- Guido
Bug#826218: Complain still interferes
Hi Guido,
Guido Günther wrote (03 Jun 2016 13:29:05 GMT) :
> On Fri, Jun 03, 2016 at 02:51:12PM +0200, intrigeri wrote:
>> I can't tell for sure until I've seen the corresponding logs, but
>> I *guess* that what's happening is: setting the usr.sbin.libvirtd
>> profile to "complain" affects that profile, and only that one; the
>> per-guest profiles libvirt generates are not affected. libvirtd is
>> still allowed to do that:
> If that would be true wouldn't undefining then redifining the domain
> (therefore switching to a different UUID resolve the problem)? I have
> tried this before and it doesn't.
Well, when doing that, a new profile (corresponding to the new UUID)
will be generated when starting up the new domain, and presumably it
will prevent the domain's startup in just the same way as the previous
profile, no?
(Still, I was mostly guessing there, and I am totally ready to accept
I was guessing wrong :)
> Note also that the problem is with starting virtlogd (which is spawned
> from libvirtd, not the VM). The issues manifests as virtlogd parsing
> incorrect stuff from the environment[1].
Now that's interesting! The logs I'm requesting below should help me
understand better what's happening:
>> To confirm this, we need:
>>
>> * the kernel / auditd logs from AppArmor, when the profile is in
>>complain or enforce mode
[... snipping logs about the parser load/etc. operations ...]
Let me be more specific: I would like to see the log about what
AppArmor blocks (the corresponding log entries should contain the
"DENIED" string).
>> * the generated profile (/etc/apparmor.d/libvirt/libvirt-${uuid}*)
> As far as can tell there are no new files generaed with the uuid of the
> sqs domain.
Hmmm, OK. Here I have to admit that I have no clue how libvirt handles
AppArmor with qemu:///session; I've never tried it myself, and I don't
even know if it's supposed to be supported. Can you reproduce this
problem with qemu:///system?
I guess that at some point I should simply try and run your
autopkgtest myself to investigate, but first if you don't mind I'd
like a little bit more input from you, until we can be certain whether
it's a bug in AppArmor or in libvirt's AppArmor integration.
Fair enough?
Cheers,
--
intrigeri
Bug#826218: Complain still interferes
Hi intrigeri,
On Fri, Jun 03, 2016 at 02:51:12PM +0200, intrigeri wrote:
[..snip..]
> > As to my understanding complain mode shouldn't have any ill effects
> > therefore I'm filing this as important.
>
> I can't tell for sure until I've seen the corresponding logs, but
> I *guess* that what's happening is: setting the usr.sbin.libvirtd
> profile to "complain" affects that profile, and only that one; the
> per-guest profiles libvirt generates are not affected. libvirtd is
> still allowed to do that:
If that would be true wouldn't undefining then redifining the domain
(therefore switching to a different UUID resolve the problem)? I have
tried this before and it doesn't. This is the full script I'm using:
https://github.com/agx/libvirt-debian/blob/debian/experimental/debian/tests/smoke-qemu-session
Note also that the problem is with starting virtlogd (which is spawned
from libvirtd, not the VM). The issues manifests as virtlogd parsing
incorrect stuff from the environment[1].
> # allow changing to our UUID-based named profiles
> change_profile ->
> @{LIBVIRT}-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*,
>
> ... if security_driver is configured to use AppArmor in
> /etc/libvirt/qemu.conf.
>
> And aa-disable does a very different thing: it full unloads the
> profile from the kernel, and then somehow libvirtd must be denied the
> change_profile operation, so the buggy auto-generated per-guest
> profile is not switched to.
>
> If my guess is right, then there's no bug in AppArmor itself (except
> perhaps change_profile should pass through the complain flag to the
> profile it switches to?).
>
> To confirm this, we need:
>
> * the kernel / auditd logs from AppArmor, when the profile is in
>complain or enforce mode
$ sudo dmesg -c > /dev/null
# Enforce
$ sudo aa-enforce /usr/sbin/libvirtd
Setting /usr/sbin/libvirtd to enforce mode.
$ debian/tests/smoke-qemu-session >& /dev/null
$ echo $?
1
$ sudo dmesg -c | grep audit
[20363.629630] audit: type=1400 audit(1464959515.310:256): apparmor="STATUS"
operation="profile_replace" name="/usr/sbin/libvirtd" pid=6608
comm="apparmor_parser"
# Complain
$ sudo aa-complain /usr/sbin/libvirtd
Setting /usr/sbin/libvirtd to complain mode.
$ debian/tests/smoke-qemu-session >& /dev/null
$ echo $?
1
$ sudo dmesg -c | grep audit
[20514.122048] audit: type=1400 audit(1464959665.801:257): apparmor="STATUS"
operation="profile_replace" name="/usr/sbin/libvirtd" pid=6695
comm="apparmor_parser"
# Diabled
$ sudo aa-disable /usr/sbin/libvirtd
$ debian/tests/smoke-qemu-session >& /dev/null
$ echo $?
0
$ sudo dmesg -c | grep audit
[20632.145135] audit: type=1400 audit(1464959783.825:258): apparmor="STATUS"
operation="profile_remove" name="/usr/sbin/libvirtd" pid=6771
comm="apparmor_parser"
> * the generated profile (/etc/apparmor.d/libvirt/libvirt-${uuid}*)
As far as can tell there are no new files generaed with the uuid of the
sqs domain.
Any more logs I can provide? Sorry if I'm looking at the wrong place.
Cheers,
-- Guido
[1] since /proc//environ looks correct I have no idea how this
relates to aa yet but it's 100% reproducible
Bug#826218: Complain still interferes
Control: tag -1 + moreinfo
Hi Guido,
Guido Günther wrote (03 Jun 2016 11:53:39 GMT) :
> I've been trying to debug why libvirt fails to start qemu:///session
> domains. Suspecting apparmor into the mix I did:
> $ aa-complain /usr/sbin/libvirtd
> $ virsh -c qemu:///session start sqs
> error: Failed to start domain sqs
> error: Failed to connect socket to
> '/run/user/1000/libvirt/virtlogd-sock': Connection refused
> Howver if I do:
> $ aa-disable /usr/sbin/libvirtd
> $ virsh -c qemu:///session start sqs
> Domain sqs started
> I've attached the domain XML to reproduce. Libvirt is 1.3.5~rc1 from
> experimental but 1.3.4 shows this as well.
Thanks for sharing!
> As to my understanding complain mode shouldn't have any ill effects
> therefore I'm filing this as important.
I can't tell for sure until I've seen the corresponding logs, but
I *guess* that what's happening is: setting the usr.sbin.libvirtd
profile to "complain" affects that profile, and only that one; the
per-guest profiles libvirt generates are not affected. libvirtd is
still allowed to do that:
# allow changing to our UUID-based named profiles
change_profile ->
@{LIBVIRT}-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*-[0-9a-f]*,
... if security_driver is configured to use AppArmor in
/etc/libvirt/qemu.conf.
And aa-disable does a very different thing: it full unloads the
profile from the kernel, and then somehow libvirtd must be denied the
change_profile operation, so the buggy auto-generated per-guest
profile is not switched to.
If my guess is right, then there's no bug in AppArmor itself (except
perhaps change_profile should pass through the complain flag to the
profile it switches to?).
To confirm this, we need:
* the kernel / auditd logs from AppArmor, when the profile is in
complain or enforce mode
* the generated profile (/etc/apparmor.d/libvirt/libvirt-${uuid}*)
Cheers,
--
intrigeri
Bug#826218: Complain still interferes
Package: apparmor Version: 2.10-4 Severity: important Hi, I've been trying to debug why libvirt fails to start qemu:///session domains. Suspecting apparmor into the mix I did: $ aa-complain /usr/sbin/libvirtd $ virsh -c qemu:///session start sqs error: Failed to start domain sqs error: Failed to connect socket to '/run/user/1000/libvirt/virtlogd-sock': Connection refused Howver if I do: $ aa-disable /usr/sbin/libvirtd $ virsh -c qemu:///session start sqs Domain sqs started I've attached the domain XML to reproduce. Libvirt is 1.3.5~rc1 from experimental but 1.3.4 shows this as well. As to my understanding complain mode shouldn't have any ill effects therefore I'm filing this as important. Cheers, -- Guido -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'unstable'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.5.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apparmor depends on: ii debconf [debconf-2.0] 1.5.59 ii libapparmor-perl 2.10-4 ii libc6 2.22-9 ii lsb-base 9.20160110 pn python3:any apparmor recommends no packages. Versions of packages apparmor suggests: pn apparmor-docs ii apparmor-profiles2.10-4 ii apparmor-profiles-extra 1.8 ii apparmor-utils 2.10-4 -- debconf information: apparmor/homedirs: smoke-qemu-session.xml Description: XML document
