Scientific Linux Forum.org



  Reply to this topicStart new topicStart Poll

> virt-manager wants users to log in as root (semi-rant), virt-manager libvirt
joeblow
 Posted: Nov 1 2012, 11:45 PM
Quote Post


SLF Junior
**

Group: Members
Posts: 41
Member No.: 236
Joined: 1-June 11









So, I decided to play with kvm and redhat's virtualization the 'right' way, e.g. using libvirt, virsh, virt-manager, and the 'nice, gooey' user interface.

So, I open up a term, type in virt-manager, and lo and behold! It wants me to log in as root.

<rant on>

For my entire career, we have discouraged logging in as root. For very good reason. "Don't log in as root" "Do everything you can with sudo" "root is asking for trouble" "Design your programs so they don't have to run as root, or if they do, they drop root priv asap". "Or if you need root priv, separate out those parts that need root priv" "Don't give out root password". "Again, never distribute root password".

Don't log in as root.

Don't use root. Use sudo.

Don't distribute root password.

Now, what do I see? EL6 wants a 'root' password before I can do anything. And since my machines are all multi-user, do I now have to give every user root password? Or otherwise assign the user root equiv?

What effin' moron at redhat made this cost-shifting decision??

And while I'm on the subject, why doesn't redhat take up a good lead from the ubuntu folks and make the effort to reduce the need for root password. Debian did, and it's a much better, more useable distro because they did.

Having to use root password for anything except the most esoteric or deep purposes is just wrong. WrongWrongWrong.

/rant off

OK.

Or am I offbase here? If so, what am I missing?
PM
^
zxq9
 Posted: Nov 2 2012, 01:44 AM
Quote Post


SLF Geek
****

Group: Members
Posts: 321
Member No.: 611
Joined: 5-August 11









You're missing that sudo is just as bad a root. In my opinion, worse, because people think its safer. At least when you login as root you know that what you are doing is dangerous. Sudo lulls you into this state where everything seems sorta kinda Ubuntuishly OK -- and you wind up with Ubuntu style problems, security being only one problem area among many.

In the case of multiple administrators where you want to have a name attached to any logged changes sudo can provide a benefit -- but the only accounts that are permitted to sudo at all are not normal user accounts to begin with and must be treated as though they are just as radioactive as the root account itself. Also, permissions on what actions/areas are sudoable should be assigned by group and... etc. This topic gets pretty large, really. Anyway, sudo in its normal Debian-inspired configuration is every bit as dangerous as logging in as root. With a basic logging configuration "su" can work fine as well, since it doesn't change the real username whereas "su -" gets tricker.

Other than that, I agree with your post. As for virtualization, it seems as though RedHat is getting friendly with the VMWare and Microsoft version of reality where OS instances are only intended to support a single use at a time, so within each nested scope of a task (each receiving its own instance) granting root in what is essentially a single-user instance anyway is not a big deal. In the race to achieve the best of the worst virtualized userland solutions everyone has forgotten that something needs to actually be running the physical hardware in a sane way for any of this to work.

But above I say "seems as though". RedHat hasn't even debated this internally yet, so I don't think they are conscious that this is the direction they are moving in -- and sailing in that direction blind is stupid. In my way of thinking this one-instance-per-function concept is deeply flawed when discussing an OS, but makes sense when discussing something like a hosted virtual environment like the JVM or treating a window manager and its libraries as if it were a virtual machine (like KDE/Qt).

I've mentioned elsewhere that I'm working on a sort of replacement for the "cloud" concept, and a lot of it hinges on moving from uberhacked document browsers as a mobile delivery platform (because browsers such as IE, Firefox, Chrome, etc. demand needless access to more sensitive parts of the host system than even window managers do!) to a deliberately designed application browser (because doing cool stuff in native apps is always easier than trying to client-side script even a truly novel widget into a document viewer).

It turns out that an application browser looks a lot like a mini window manager of its own that is quarantined from the rest of the system. Conversely, turning Firefox and IE into discreet window managers of their own is what everyone has been unconsciously failing at for the last decade and the reason they demand access to so many seemingly odd system resources. If a decent application browser looks like a miniature quarantined window manager, then a mini window manager turns out to look like is a stripped down VM instance. Note the "stripped down" bit there -- doing this with a whole OS is either going to screw the user, screw the OS or both.

But designing new things is hard, so what everyone else is doing is virtualizing the entire OS just to provide a host for a hacked up document viewer like IE or Firefox and then deliver web applications (which are just hacked up document sets) through them. And then call the result a "platform" (note that what they are really calling the platform is the browser, not the OS) and the documents (websites) you access through them "applications" -- which is, of course, ridiculous.

It doesn't seem to have dawned on anyone just yet that the compromises necessary to turn a serious OS into an on-off userland application render the underlying OS unsuitable to be the main host of the hardware I mentioned above. The consequences of those compromises are, in effect, what you are complaining about. This goes a lot deeper than sudo VS root, right down to the core of the current struggle for the soul of our operating systems.

Hopefully this explanation was coherent; I haven't had my coffee yet.
PMEmail PosterUsers Website
^
joeblow
 Posted: Nov 2 2012, 04:40 PM
Quote Post


SLF Junior
**

Group: Members
Posts: 41
Member No.: 236
Joined: 1-June 11









your point about sudo vs root is well taken. As is your discussion of the (wrong) direction away from true multi-user multi-app uses; linux is certainly capable, but the practice and methods are being abandoned and forgotten (insert obligatory wistful sigh for the lost VMS).

Being simplistic, in the case of kvm and virt-manager, the better, if not ideal, approach is, say, a 'kvm' or 'vm' or 'virt' or some such group. If a username is in the kvm group, then s/he can log into virt-manager (or whatever) and do virtual machine things. If the user is not in the kvm group, then nothing associated with kvm is even visible to the user.

Also, in this scenario, there is no need for the user to have any knowledge of 'root' at all.

And...and...and...there's just so many good reasons, but it also means more work from the developers.

OK, back to paid work now. Thanks for listening.

PM
^
zxq9
 Posted: Nov 4 2012, 11:57 AM
Quote Post


SLF Geek
****

Group: Members
Posts: 321
Member No.: 611
Joined: 5-August 11









You can configure your system to work the way you describe, and I do something very similar to this myself -- creating groups that can do certain things and to that end I do make extensive use of sudo because logging is really easy if you use it to its fullest.

As for the first bit about Linux being a capable system -- it certainly is, for nearly anything. But Linux is not an operating system and has nothing to do with using sudo or su. A chopped down kernel that is purpose built to be a virtual client system is a cool idea and should be explored -- but this is not what people are doing. We're nesting entire distros into the same distro and then forgetting that whenever we make a security compromise on one of the "throw away" instances in the interest of ease of use we just set a dangerous default for the entire distro, including the underlying host. Oops.

For this reason I'm getting more interested in Hurd as an underlying kernel for the whole shebang and then using a purpose built Linux on top of that -- or maybe the other way around. (the trick to the debate here is where do we want to pay the costs associated with maintaining a microkernel to get its interesting benefits?) In any case a clear distinction between what is the underlying "boring" host and what are the more exciting guests should be made and stuck to. Your comment about VMS is not missed on me. I have to say I've grown spoiled in the new age a little bit and I'd never want to go back to scripting the VMS shell compared to what's available in Unix these days, but having an underlying hardware host of that caliber would make life a lot easier. Its ironic that that's the role Linux itself used to fill until recently when we absorbed so many Windowsy devs... but that's a different discussion I've already beat to death elsewhere.
PMEmail PosterUsers Website
^
joeblow
 Posted: Dec 4 2012, 07:26 PM
Quote Post


SLF Junior
**

Group: Members
Posts: 41
Member No.: 236
Joined: 1-June 11









So how do you set up a, say, kvm group (or let's say a 'vm-users' group) and set it up so that a user in the vm-users group can use virt-manager?

I am comfortable with acl's, but it still seems at some point there is a need for root access (which parts of course have not been split out). Do you set up a sudo group and limits for this?

PM
^
joeblow
 Posted: Dec 4 2012, 07:29 PM
Quote Post


SLF Junior
**

Group: Members
Posts: 41
Member No.: 236
Joined: 1-June 11









and crap. Trying to use virt-manager to remote access the vm's on a remote box. It wants to ssh as root. We've got root logins blocked at the login.block level and sshd_config level.

damndamnstupid. can you say catch-22?

PM
^
helikaon
 Posted: Apr 5 2013, 01:28 PM
Quote Post


SLF Administrator
*******

Group: Admins
Posts: 836
Member No.: 4
Joined: 8-April 11









QUOTE (joeblow @ Dec 4 2012, 07:29 PM)
and crap.  Trying to use virt-manager to remote access the vm's on a remote box.  It wants to ssh as root.  We've got root logins blocked at the login.block level and sshd_config level. 

damndamnstupid.  can you say catch-22?


Old post, but nvm, i needed to solve similar sit - having using the KVM on my laptop.
Apparently, i know my root pw, i just got tired after some time to supply root pw every time i need to run 'virt-manager' as normal user.

Solution is to use 'polkit'.
try:
CODE

man 8 pklocalauthority
man polkit


To get more understanding if you're not familiar with it.

now, create file:

/etc/polkit-1/localauthority/50-local.d/50-virt-manager-local-access.pkla

and insert
CODE

[Allow group your-group-name libvirt management permissions]
   Identity=unix-group:your-group-name
   Action=org.libvirt.unix.manage
   ResultAny=yes
   ResultInactive=yes
   ResultActive=yes


your-group-name=name of grp where the user that need to run 'virt-manager' is part of.

cheers,



--------------------
PMEmail Poster
^
DaveyCyana
 Posted: Aug 21 2013, 08:45 AM
Quote Post


SLF Newbie


Group: Members
Posts: 2
Member No.: 2673
Joined: 16-August 13









I don't think they are conscious that this is the direction they are moving in.

--------------------
Jazz up your closet with some fabulous must haves sexy beach dress uk as follow.
PMUsers Website
^
roscopcoltrane
 Posted: Aug 30 2013, 09:35 AM
Quote Post


SLF Newbie


Group: Members
Posts: 2
Member No.: 2691
Joined: 30-August 13









For the people who google here and wonder how to do it the proper way, just have a look at:

/etc/libvirt/libvirtd.conf

and edit the section beginning with:

#################################################################
#
# UNIX socket access controls
#

# Set the UNIX domain socket group ownership. This can be used to
# allow a 'trusted' set of users access to management capabilities
# without becoming root.
#
# This is restricted to 'root' by default.
#unix_sock_group = "libvirt"

# Set the UNIX socket permissions for the R/O socket. This is used
# for monitoring VM status only
#
# Default allows any user. If setting group ownership may want to
# restrict this to:
#unix_sock_ro_perms = "0777"

# Set the UNIX socket permissions for the R/W socket. This is used
# for full management of VMs
#
# Default allows only root. If PolicyKit is enabled on the socket,
# the default will change to allow everyone (eg, 0777)
#
# If not using PolicyKit and setting group ownership for access
# control then you may want to relax this to:
#unix_sock_rw_perms = "0770"

# Set the name of the directory in which sockets will be found/created.
#unix_sock_dir = "/var/run/libvirt"



Can we agree that this "case" (I don't even call it a problem) wasn't worth all this rant ?
PM
^
0 User(s) are reading this topic (0 Guests and 0 Anonymous Users)
0 Members:

Topic Options Reply to this topicStart new topicStart Poll