On 06/05/2012 09:08 AM, Alexander Graf wrote:
On 05.06.2012, at 03:03, Anthony Liguori wrote:
On 06/05/2012 08:55 AM, Alexander Graf wrote:
On 05.06.2012, at 01:54, Anthony Liguori wrote:
Have you ever experienced a random failure on an SELinux box that made no
logical sense? Out of desperation, you setenforce 0 and magically, thinks work
again.
Yeah - I never understood how anyone thought it makes sense to enable SELinux
globally be default.... Either way, FIPS hopefully isn't something you find
enabled by accident anywhere.
Even if the user enabled fips mode, they may not understand that this means VNC
authentication will stop working. Providing an option (1) allows the user to
discover what the problem is (2) makes the behavior much more clear.
Where would you want the option to live? Compile time would be useless - users
don't recompile QEMU, they take binary packages. A runtime option? Who would
enable that runtime option then? Libvirt by default I suppose? So you're back
in the same hell. RH would patch libvirt to always pass in -enable-fips and
nothing would be different.
A QemuOpts option that is disabled by default but can be enabled through
/etc/qemu/target-x86_64.conf
If any distribution wants to enable it as part of the default configuration,
they certainly can. But a user can override it if they want to.
Likewise, libvirt can enable it by default if they are so inclined. At least
the qemu logs from libvirt will show -enable-fips-mode
Removing features based on a magic procfs variable with no input from the user
is a bad idea IMHO.
But it's the design of the Linux FIPS model.
Just because someone made a bad choice, that doesn't mean we have to continue
to make bad choices ourselves.
This whole feature is ridiculous from a technical perspective. As you said,
disabling VNC auth but allowing no-password to be used is simply moronic.
I understand why we have to support these things, but it should not be the
default behavior.
Fair enough, but I don't think a
### log file ###
qemu-kvm<a lot of options> -enable-fips<a lot of other options>
### end of log file ###
vs
### log file ###
qemu-kvm<even more options> <option that sets vnc password>
WARNING: your VNC password has just been deactivated
### end of log file ###
make too much of a difference.
Which gets me to a new idea. Why not exit(1) when we detect FIPS and a password
is set? I agree with the assessment that we should never silently drop
features. So the best way to make sure that the user knows he did something
stupid (enable FIPS, but require a non-FIPS compliant authentication method)
would be to just quit, no?
I think my primary requirement is: allow a user to use vnc authentication even
when fips mode is active by using some command line option.
Regards,
Anthony Liguori
That way everyone should be happy. Users can't run VMs with FIPS&& vnc
password, we don't have to enable new command line options and whoever does the UI can
also check the same thing and just not expose the vnc password field.
Alex
