_On the last version of HP-UX and VM Host this is the Provide Access
to VM Consoles_ :
- Access can be given to users/groups who have VM Host shell access.
- You may also create a *captive* user account:
# useradd -s /opt/hpvm/bin/hpvmconsole \
-r no -d /var/opt/hpvm/guests/vm1 vm1oper
# passwd vm1oper
The /var/opt/hpvm/guests/ is the special directory of any Virtual
Machine write a system log. I have many folders as VM host.
+ When vm1oper logs in to the VM Host, vMP (virtual Management
Processor) for vm1 will start (no VM Host shell access)
- Two privilege levels: admin or oper
- Authorize users or groups:
# hpvmmodify -P vm1 -u vm1oper:oper
# hpvmmodify -P vm1 -g vm1admins:admin
I searched on Google and many forums but have not found anything that
I have been helpful.
The man online don't help me (man -s5 zones, man -s5 attributes, ecc.)
_What do you think of this solution for Solaris 10_ :
global# useradd -c "zlogin -C user console to z1" \
-s "/usr/sbin/zlogin -C z1" \
-d <z1 zonepath> z1oper
To be more security use the Solaris "roles"? Turn protect myself from
possible exploits...
The user default home directory(<z1 zonepath>) it's correct for this
user use?
I am interested in your opinion especially when it comes to security.
Any suggestions is greatly appreciated.
-Thanks and Regards
P.S.: Excuse me for bad English, but Italian ;-)
I have done this on my local Laptop. /etc/security/exec_attr contains
Zone Management:solaris:cmd:::/usr/sbin/zlogin:uid=0
This is the Profile Zone Management which is a profile.This profile
can be assigned to the users which should be allowed to do zone
management.
They need to use a profile aware shell like pfsh,pfcsh or pfexec to
utilize the profile.
The /etc/user_attr contains the data, which profiles the user is
allowed to have.
This is my profile
bash-3.2$ profiles
Brightness
Console User
Suspend To RAM
Suspend To Disk
CPU Power Management
Network Wifi Info
Primary Administrator
Zone Management
Basic Solaris User
All
bash-3.2$ pfexec zlogin -C centos5
[Verbunden mit Konsole für Zone 'centos5']
or you can define a role ( something like a user, but can not directly
login in via a session ),
to which the zone admins have to change before.
Have a look into RBAC.
HTH
Ewald
On Apr 20, 9:04 pm, Michele Vecchiato <michele.vecchi...@gmail.com>
wrote:
The comment at
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/zlogin/zlogin.c#1792
clearly says that no way is presently provided to do what you want.
> _What do you think of this solution for Solaris 10_ :
>
> global# useradd -c "zlogin -C user console to z1" \
> -s "/usr/sbin/zlogin -C z1" \
> -d <z1 zonepath> z1oper
Won't work because
* the shell for an account can't have any arguments (could use a
script to get around that, but _not_ a good idea to do so)
* would still need the account to use uid 0 for zlogin
> To be more security use the Solaris "roles"? Turn protect myself from
> possible exploits...
> The user default home directory(<z1 zonepath>) it's correct for this
> user use?
>
> I am interested in your opinion especially when it comes to security.
>
> Any suggestions is greatly appreciated.
See the thread
http://www.opensolaris.org/jive/thread.jspa?threadID=99270&tstart=0
Go to the bottom, get the _latest_ version of zconsole.c that I posted.
It is just a tricky wrapper around zlogin. It needs to be compiled and
installed setuid root. When it runs, it gives up root privilege except
when it executes zlogin.
One would also need a line like
local.zone.console.:::Zone Console Access::
added to auth_attr, and for each _zonename_ one wishes to
delegate access to, a line like
local.zone.console._zonename_:::_zonename_ Zone Console Access::
added as well. Then, for each account one wishes to give access to
a zone, add the corresponding authorization to their user_attry entry.
Here's what mine looks like (simplified to get rid of everything else):
rlhamil::::auths=local.zone.console.*;type=normal
That allows my zconsole program to grant access to my account for _all_
non-global zones (because of the asterisk). I could have instead given
a list, like
auths=local.zone.console.zonea,local.zone.console.zoneb
or just a single zone
auths=local.zone.console.zonea
I suppose one could add such authorizations to roles as well as individual
accounts, although I haven't specifically tried,
If one runs
zconsole _zonename_
it takes one directly to the zone console (as zlogin -C _zonename_) if
one is allowed access. If one runs just
zconsole
it shows a menu of all the zones one has access to, and keeps coming
back to that until one enters a 'q' to exit the menu. In that latter
mode, it could be used as a login shell for an account of a zone
administrator on the global zone.
Better would be if zlogin itself did what my program does. But this
was something I did fairly quickly, without trying to have it added
to zlogin. If I have any more updates to it, I may post them in the
same place. But I have no particular interest in doing anything more
than demonstrating what I think is one reasonably simple solution, which
I think I have done.
(To those who think that the existing Zone Management profile is
sufficient, it isn't because it allows access to _all_ zone consoles,
as well as the ability to create, delete, or modify all zones; not just
console access to individual (or specified) zones only.)
> Better would be if zlogin itself did what my program does. But this
> was something I did fairly quickly, without trying to have it added
> to zlogin. If I have any more updates to it, I may post them in the
> same place. But I have no particular interest in doing anything more
> than demonstrating what I think is one reasonably simple solution, which
> I think I have done.
>
OK...stay tuned.
> (To those who think that the existing Zone Management profile is
> sufficient, it isn't because it allows access to _all_ zone consoles,
> as well as the ability to create, delete, or modify all zones; not just
> console access to individual (or specified) zones only.)
Thanks for the comprehensive reply and for the time you devoted to
this problem.
Michele
--
http://michelevecchiato.wordpress.com
I'm not sure this will work but maybe it is an option for you-
Maybe connect zlogin -C <zone> to a tty (instead of /usr/bin/login)?
You will be relying on the login after the console connection for
security.
You may also need to access the tty from the global zone- I would
guess you don't need root for that.
You might also be able to delegate the tty into the zone to make it
accessible from inside.
Good luck,
Yonah
--
http://www.yonahruss.com/
On Apr 24, 12:10 am, Michele Vecchiato <michele.vecchi...@gmail.com>
wrote:
> On 21 Apr, 21:39, rlha...@smart.net (Richard L. Hamilton) wrote:
> ...> The comment athttp://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/zlo...
>
> I'd thought :( Thanks for the code source indication...
> ...> clearly says that no way is presently provided to do what you want.
>
> I had a suspicion... but your comment has confirmed to me.
> ...> Won't work because
> > * the shell for an account can't have any arguments (could use a
> > script to get around that, but _not_ a good idea to do so)
>
> have agreed with you> * would still need the account to use uid 0 for zlogin
>
> OK. Any user account with UID=0 is as "root account clone" and i don't
> want.
> ...
>
> > See the threadhttp://www.opensolaris.org/jive/thread.jspa?threadID=99270&tstart=0
Here's a potential solution:
1) Configure /etc/ssh/sshd_config with the following option and then
restart the ssh service:
"PermitRootLogin forced-commands-only"
2) Generate an SSH key pair with "ssh-keygen" and add the public key
to the root user's "~/.ssh/authorized_keys" as follows:
command="/usr/sbin/zlogin -C <zone_name>" <SSH_public_key>
3) Give the private key to the user you want to allow access to the
zone console. He should be able to "ssh root@<globalzone>" using the
private key to authenticate and run the defined "zlogin" command.
It should be possible to generate multiple keys allowing different
keys access to different zone consoles. From a security standpoint,
this does allow a remote connection as the global zone root, but it
*should* be limited to the command defined in the authorized_keys
file. I'd welcome any comments on the security implications of this
approach.