I think the customer would be very interested in this tool, however
one of the gripes is that things of this nature aren't built in
and that they have to construct 'add-ons' to build a base SOE system.

Glenn Brunette wrote:


It was basically for this reason that I wrote up a small tool called
rzlogin a while back.  This particular tool was focused solely on
restricting access to zone console logins, but it did leverage some
of the ideas called out by David Comay in 4963290 - namely using
Solaris authorizations to grant users/roles access to specific
zones consoles.

The rzlogin tool went a little further by providing some additional
logging (entry and exit, unauthorized access attempts) as well as
keystroke logging while the user was access the zone's console.
The logs were sent to syslog since frankly few of my customers are
using Solaris audit and the keystroke logs were stored in a root
owned protected directory in the global zone to prevent tampering
(by the non-global zone administrators using the tool).

This script was originally intended as a simple demonstration for
how RBAC could be enhanced using small wrappers to provide some
interesting kinds of functionality.


Brian Kolaci wrote:

Its more of a separation of duties.  The zone management admin is
not necessarily the same person as the application admin in a local
zone (however it could be the same person, then this particular item
would be moot).  The management is bad, but thats just the way it
is and always was.  Audit requires that tools be in place so that
they can't shoot themselves in the foot and also to stop malicious
users that can steal someone elses password from too much damage.

If you separate the duties so that there's no one person with
global privileges, that goes a long way.  The two-man rule is another
complimentary approach to some high-risk secure tasks, however it
should be enough to make sure the people have just enough privilege
to do their jobs/tasks.

Michael Barto wrote:

This probably sacrilege, but some of these zone security issues might be better served with Secure Solaris, if the security requirements are this extreme (e.g . DOD). Adding complex security always add complex overhead. On the other hand locking out the global zone to all purposes and administrators except for managing zones (nothing else) creates less security overhead. Diving servers into manage sets (this group, that group, accounts payable, accounts receivable) instead of sharing between groups can also keep the security overhead low. Everyone things they can write programs to correct bad management instead of trying to correct bad management.

Brian Kolaci wrote:

IHAC that is looking to split out zone management roles.

The zone administrator creates and manages the local zones
however that person should not be able to see the data
in the zone for security purposes.  They should only be able
to manipulate the resources assigned to the zone, as well
as create/destroy zones.

The issue that comes up is that zlogin automatically grants
them unauthenticated root privileges in the zone.  Console access
should be fine since that is authenticated, however the default
without -C gives them full access.  So with the current scenario
its an all or nothing proposition.

I propose that zlogin be split into two different programs, one
for console access and one for running programs and/or shell.
A simple way to do this (and would be backward compatible) would be to
create a hard link to zlogin, say 'zconsole' that when it is executed
the program can test arg0 and automatically apply the -C functionality
if it is called zconsole.  This would allow better separation of
duties and allow two different profiles in exec_attr to differentiate
what zone administrators can do.



zones-discuss mailing list

*Michael Barto*
Software Architect

    LogiQwest Circle
LogiQwest Inc.
16458 Bolsa Chica Street, # 15
Huntington Beach, CA  92649

            [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
Tel:  714 377 3705
Fax: 714 840 3937
Cell: 714 883 1949

*'tis a gift to be simple*
This e-mail may contain LogiQwest proprietary information and should be treated as confidential.


zones-discuss mailing list

zones-discuss mailing list

zones-discuss mailing list

Reply via email to