[zones-discuss] zone management and security
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. Thanks, Brian ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone management and security
Jeff Victor wrote: 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. The other issue is that the GZ admin can read any files in a zone without using zlogin. The only exception to that is a fs that the non-GZ admin NFS-mounts, and that exception will only last until a few CR's are delivered. Two items on this front. First, I was referring to someone (not root) that has the Zones Management profile which gives them zoneadm, zonecfg and zlogin. Second, I've recommended that they convert root to a role and strip privs (such as file_dac_read, file_dac_write) and protect the filesystems and zonepaths as well as write access to user_attr, exec_attr, etc. 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. Sounds like a good answer. It seems to me that the GZ admin could implement this by writing a short program. What am I missing? Just the piece I mentioned above. One of the goals is to strip privs from the root account since not even root should be able to see the data in the local zones on a secure server. The ability to manage zones should be isolated from the ability to view content in the zones. This should be out of the box and not something that the customer needs to write/implement themselves. The backward compatible proposal above would just be a step to getting there. ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone management and security
Brian Kolaci wrote: Jeff Victor wrote: 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. The other issue is that the GZ admin can read any files in a zone without using zlogin. The only exception to that is a fs that the non-GZ admin NFS-mounts, and that exception will only last until a few CR's are delivered. Two items on this front. First, I was referring to someone (not root) that has the Zones Management profile which gives them zoneadm, zonecfg and zlogin. Second, I've recommended that they convert root to a role and strip privs (such as file_dac_read, file_dac_write) and protect the filesystems and zonepaths as well as write access to user_attr, exec_attr, etc. What method will be used to prevent a zone admin from creating another zone, mounting the fs with sensitive info in that zone, logging into the new zone as root, and viewing the data? -- Jeff VICTOR Sun Microsystemsjeff.victor @ sun.com OS AmbassadorSr. Technical Specialist Solaris 10 Zones FAQ:http://www.opensolaris.org/os/community/zones/faq -- ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone management and security
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. Thanks, Brian ___ zones-discuss mailing list zones-discuss@opensolaris.org -- Michael Barto Software Architect LogiQwest Inc. 16458 Bolsa Chica Street, # 15 Huntington Beach, CA92649 http://www.logiqwest.com/ [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@opensolaris.org
Re: [zones-discuss] zone management and security
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. There have been some discussion of using SMF authorizations with zones to provide this level of control. One CR of interest is 4963290 RFE: implement flexible zone administration that doesn't require uid=0 dsc ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone management and security
On 10/13/06, Michael Barto [EMAIL PROTECTED] 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. A problem I see with that approach (Global Zone is for management of NG Zones only) is what happens in the case of a system that is not using NG Zones. Right now a Solrais 10 system out of the box is a Global Zone. Would the tools need to be aware if there were any NG Zones and act differently ? That doesn't seem like a good idea to me. BTW, that is the way we treat the Global Zone (creation and management of NG Zones). No services run out of the Global Zone unless it is required to be in the Global Zone (NFS server, NTP, etc.). Perhaps going in the direction of Secure Solaris, there should be an option at installation to choose Restricted or Trusted Global Zone, although that has it's own set of issues. -- Paul Kraus ___ zones-discuss mailing list zones-discuss@opensolaris.org
Re: [zones-discuss] zone management and security
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: Brian, 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. g 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. Thanks, Brian ___ zones-discuss mailing list zones-discuss@opensolaris.org -- *Michael Barto* Software Architect LogiQwest Circle LogiQwest Inc. 16458 Bolsa Chica Street, # 15 Huntington Beach, CA 92649 http://www.logiqwest.com/ [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@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org ___ zones-discuss mailing list zones-discuss@opensolaris.org
