[libvirt] [PATCH] apparmor: allow qemu abstraction to read /proc/pid/cmdline

[Jamie Strandboge]

On Mon, 2017-12-04 at 12:03 +0100, Michal Privoznik wrote:
> On 12/01/2017 02:26 PM, Jamie Strandboge wrote:
> > On Thu, 2017-11-30 at 10:43 -0700, Jim Fehlig wrote:
> > > Noticed the following denial in audit.log when shutting down
> > > an apparmor confined domain
> > > 
> > > type=AVC msg=audit(1512002299.742:131): apparmor="DENIED"
> > > operation="open" profile="libvirt-66154842-e926-4f92-92f0-
> > > 1c1bf61dd1ff"
> > > name="/proc/1475/cmdline" pid=2958 comm="qemu-system-x86"
> > > requested_mask="r" denied_mask="r" fsuid=469 ouid=0
> > > 
> > > Squelch the denial by allowing read access to
> > > /proc/<pid>/cmdline.
> > > 
> > > Signed-off-by: Jim Fehlig <jfehlig at suse.com>
> > > ---
> > > 
> > > Note: In the audit.log snippet, PID 1475 is libvirtd and 2958 is
> > > the
> > > qemu process. I must admit it is not clear to me why
> > > /proc/<libvirtd-pid>/cmdline is read on domain shutdown.
> > > 
> > >  examples/apparmor/libvirt-qemu | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/examples/apparmor/libvirt-qemu
> > > b/examples/apparmor/libvirt-qemu
> > > index 73bdbae87..3d9eed9ec 100644
> > > --- a/examples/apparmor/libvirt-qemu
> > > +++ b/examples/apparmor/libvirt-qemu
> > > @@ -25,6 +25,7 @@
> > >    /dev/ptmx rw,
> > >    /dev/kqemu rw,
> > >    @{PROC}/*/status r,
> > > +  @{PROC}/@{pid}/cmdline r,
> > 
> > Note this is an information leak and allows reading potentially
> > sensitive information, such as passwords given on the command line.
> > Eg:
> > 
> > $ cat /proc/13335/cmdline | tr '\0' ' '
> > sh /tmp/testme --password=sensitive
> 
> Well, I'd say that passing passwords (or any sensitive information)
> through command line is doomed by definition. Anybody can read that
> (doing mere ps is enough).
> 
> > 
> > Would it be possible to use 'owner' match? Eg:
> > 
> >   owner @{PROC}/@{pid}/cmdline r,
> 
> Okay, this narrows the attack surface, but I guess that somebody else
> doing `ps' on the system will be able to obtain the password anyway.

Sure, but what is different here is that the qemu processes are
intended to be confined/untrusted whereas other processes on the system
(eg, the user's shell) are not. Therefore, IMO, we should try to avoid
information leaks in the qemu policy where possible.

-- 
Jamie Strandboge             | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20171204/9fa115d9/attachment-0001.sig>