Re: [libvirt] FYI: Updated QEMU driver docs on security model

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2009-08-19 at 14:32 +0100, Daniel P. Berrange wrote:
> FYI, I just pushed the following patch to the repo which adds documentation
> to the website for all the security model related aspects of libvirt's
> QEMU driver. It should appear here shortly
> 
>   http://libvirt.org/drvqemu.html

Looks good, mostly just typos below

ACK etc.

> +    <h3><a name="securitydac">POSIX DAC users/groups</a></h3>
> +
> +    <p>
> +      In the "session" instance, the POSIX DAC model restricts QEMU virtual

Should expand the acronym, it's pretty obscure

> +    <p>
> +      If QEMU virtual machines from the "system" instance are being
> +      run as non-root, there will be greater restrictions on what
> +      host resources the QEMU process will be able to access. The
> +      libvirtd daemon will attempt to manage permissions on resources
> +      to minise the likelihood of unintentionale security denials,

'minimize' or 'minimise'

Clearly, en_GB is correct, but isn't the rest of the doc bogus en_US?

No 'e' in unintentional either


> +      but the administrator / application developer must be aware of
> +      some of the consequences / restrictions.
> +    </p>
> +
> +    <ul>
> +      <li>
> +        <p>
> +          The directories <code>/var/run/libvirt/qemu/</code>,
> +          <code>/var/lib/libvirt/qemu/</code> and
> +          <code>/var/cache/libvirt/qemu/</code> must all have their
> +          ownership set to match the user / group ID that QEMU
> +          guests will be run as. If the vendor has set a non-root
> +          user/group for the QEMU driver at build time, the
> +          permissions should be set automatically at install time.
> +          If a host administrator customizes user/group in
> +          <code>/etc/libvirt/qemu.conf</code>, they will need to
> +          manually set the ownership on these directories.

It's good to have this documented, but I'd much prefer us to handle it
automatically

e.g. libvirtd knows that if the permissions on the dir is wrong, the
guest won't start

So, it could warn the user, or create an alternative directory and chown
it or ...

> +        </p>
> +      </li>
> +      <li>
> +        <p>
> +          When attaching PCI and USB devices to a QEMU guest,
> +          QEMU will need to access files in <code>/dev/bus/usb</code>
> +          and <code>/sys/bus/devices</code>. The libvirtd daemon

/sys/bus/usb/devices

Neither are related to PCI devices

> +          will automatically set the ownership on specific devices
> +          that are assigned to a guest at start time. There should
> +          not be any need for administrator changes in this respect.
> +        </p>
> +      </li>
> +      <li>
> +        <p>
> +          Any files/devices used as guest disk images must be
> +          accessible to the user/group ID that QEMU guests are
> +          configured to run as. The libvirtd daemon will automatically
> +          set the ownership of the file/device path to the correct
> +          user/group ID. Applications / administrators must be aware
> +          though that the parent directory permissions may still
> +          deny access. The directories containing disk images
> +          must either have their ownership set to match the user/group
> +          configured for QEMU, or their UNIX file permissions must
> +          have the 'execute/search' bit enabled for 'others'.
> +        </p>
> +        <p>
> +          The simplest option is the latter one, of just enabling
> +          the 'execute/search' bit. For any directory to be used
> +          for storing disk images, this can be achived by running

archived

> +    <p>
> +      If the sVirt security model is active, then the node capabilties

capabilities 

Cheers,
Mark.

--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]