Howdy Greg! This initial proposal is for the new install model for the Solaris Express Developers install base which is mainly desktops and laptops.
So that is the bottom line for this proposal, but if you want to read on, I will attempt to explain my way of thinking and reasoning. First of all it depends. Like lots of things, it depends on the business environment, business requirements and what acceptable risk the business is willing to accept. It has been my experience that anytime anyone mentions controlling root it starts religious wars. Another thing is anytime anyone suggests controlling root, system administrators feel uneasy because there is always the fear factor. What if? What if I cannot do my job correctly? Or if you control root you are making my job harder to do and I am over burden as it is. Why introduce complexity? What wrong with doing it the old way? It works, why fix it? Well, that is how I felt at one point. I was like this when my information security guys wanted to implement things like power broker or sudo 10 years ago. I know the fear is real and the horror stories are real, I was once a systems administrator and then a security guy so I have sat on both sides of the fence. What I have come to see is it takes an extra step and a little getting use to but you gain so much more control over your environment when you control root. With Solaris 10 and the ability to implement right management for both process and users is really cool! I can know delegate root privileges and restrict any privileges I want. For example I can allow the backup administrator to run his jobs without giving out root, as I just give him the one or two privileges he need to get his job done. With Solaris 10 privileges you can grant privileges to users directly as rights or through roles. Root is no longer an all or nothing proposition. Regardless if my system is a laptop or an F25, root in my opinion should be a role. For me, in an ideal security world, root in my opinion should be a role in multi-user mode. There is no need for the someone to have all root powers without accountability. Root should not be an all or nothing proposition. All users should be audited and held accountable for their actions. All users should have all the rights and privileges required to do their job. Depending on job functions, most everyday administrative functions really only require a small subset of root privileges. For instance there could be a Primary Administrator Role (root equivalent with accountability), a Systems Administrator Role, a Security Administrator Role, Operator Role, Backup Role, etc... Also a big side of effect of using roles today is it provides auditing and accountability benefits which can also support businesses with SOX requirements. So in a scenario where there is no access by normal users to login to a server in a data center because of name service issues, that should be alright, because system administrators in an ideal security environment would be able to login to their servers via a management framework. A well defined management framework strategy usually has a well documented process and its own management network resources. This means that normal users would not know about this management framework or have access to these resources and a system administrator would. Also most production data center environments usually tend to run higher end systems with lots of RAS features and security built-in to these servers. Things such as ALOM/ILOM for lights out type of management. Access to these systems for server management actually are performed initially at a lower level below the OS level. They require logging into a terminal concentrator or login via a private network to access the ALOM/ILOM. From the ALOM/ILOM console you can then get to an OS level console to perform your OS maintenance tasks. In single user mode there is only root login for maintenance. Root delegated rights and privileges can only occur once you exit single user mode. The OS service that starts role based access controls and privileges occurs in multi-user mode. Once in multi-user mode a system user name assigned primary administrator rights can login as themselves and can perform any root tasks by simply typing "pfexec" and whatever root commands they need to run. To play with this and to see how simple it is to use, requires running Solaris 10 or one of the Solaris Express builds. The following is a quick example to get started using the Solaris Management Console (SMC): at the command line type "smc&" (if this is the first time it can take a minute or two) double click on Computer double click on System Configuration double click on Users when prompted to login, login as root double click on User Accounts double click on your user name click on Rights tab scroll down Available Rights list until you see Primary Administrator click on Primary Administrator click on Add click on OK click on Console in main bar at the top in the header click on exit and you are done Your user name now has Primary Administrator Rights which mean you can run all root commands. A quick test of these rights and privileges can be performed by simply typing "pfexec" and then whatever root command you want to run. For example to plumb an interface for your system type "pfexec ifconfig -a plumb", this will plumb your network interface card if one exists and if it is not already plumbed. Again Solaris 10 allows you to delegate rights or to assume a role using role based access control (RBAC). In this example we delegated rights to our user name and just by typing pfexec we are able to run those privilege commands delegated to our user. Using RBAC you can require a user to assume a role in that case the user would have to type in his password and reauthenticate to assume that role. There is a lot more information on rights management at docs.sun.com and opensolaris.org in the security community. Thanks! Wences Gregory Shaw wrote: > I'd like to add something. Correct me if I'm wrong, but as I > understand it, if you can't log in as a regular user, you can't do > anything as root. > > So, should NFS time out on a login, or some other similar situation > occur (name services broken, etc.), you can't log in as the user, and, > you can't log in as root to fix the system. > > This works just fine for a laptop, as there are no external > dependencies. However, as soon as you make it more complex, it > becomes a show stopper. > > I've had to fix far too many broken systems in the middle of the night > as root to want to lose that functionality. Many of the systems were > in such a bad state that they only barely made it to single user. > > Just my $.02. > > On Apr 10, 2007, at 10:59 AM, Wences.Michel at Sun.COM > <mailto:Wences.Michel at Sun.COM> wrote: > >> Howdy! >> >> I think this is a great idea! >> >> Except I would suggest being a little bit more aggressive. By >> default, this should be as it is done in MAC OS X; during install, >> create a user account and add primary administrator to that account >> up front no questions aked, no way to opt out. >> If user really wants to activate root, they should purposely have to >> go do that after the install. Of course we would need to educate the >> system administrators about this new "default install" and tell them >> how to use pfexec when they need to run things as root. >> If you think this is to harsh for all cases, you may want to consider >> that for special Use Cases, where there is a hard requirement for >> installing root up front, you could add some kind of legacy flag to >> opt out of the "default install" or just make that type of install >> part of a customized install. >> Again thanks to all and kudos for thinking about this type of >> "default install"! >> >> Thanks! >> >> Wences >> >> >> Sarah Jelinek wrote On 04/10/07 10:45,: >> >>> Hi Darren, >>> >>> Thanks for the info...my comments inline... >>> >>>> Sarah Jelinek wrote: >>>> >>>>> Hi Darren, >>>>> >>>>> >>>>> Darren J Moffat wrote: >>>>> >>>>>> In the brave new installer world I believe there will be the >>>>>> ability during interactive install to create (normal) users. >>>>>> >>>>> Sort of, we are planning on creating privileged accounts. >>>> >>>> >>>> We don't actually use the term "privileged account" in Solaris. >>>> >>>> This is because privileges(5) are an attribute of a process. >>>> Rights profiles and authorisations is what users get. >>> >>> Ok. >>> >>>> >>>>> We were actually looking at a System Administrator RBAC profile. >>>>> The original documents stated that the user account created would >>>>> not be privileged, but after discussion we a realized we needed to >>>>> allow an administrator to be created during install time. From >>>>> what I understand the difference between the System Administrator >>>>> and Primary Administrator RBAC profiles is that the System >>>>> administrator can do things like manage filesystems, installation >>>>> of software, but can't set passwords, and is not equivalent to the >>>>> root user. What are your thoughts about setting the user account >>>>> to the >>>> >>>> >>>> Primary Administrator >>>> >>>>> rather than System Administrator? >>>> >>>> >>>> There is no 'System Administrator' RBAC profile today so that would >>>> need to be defined. I think it is probably easier for the install >>>> project to use a profile that already exists rather than trying to >>>> create a new one. >>>> >>> Really? Ok, I admit I don't know a lot about this, so I have been >>> reading the docs on this to understand what is available to us, and >>> it states there is a System Administrator rights profile: >>> >>> http://docs.sun.com/app/docs/doc/819-3321/6n5i4b77u?q=rbac&a=view >>> <http://docs.sun.com/app/docs/doc/819-3321/6n5i4b77u?q=rbac&a=view> >>> >>> That's where I got the data from. >>> >>>> The reason for picking 'Primary Administrator' is that it makes the >>>> experience on Solaris very similar to other systems where sudo >>>> rather than RBAC is used and the default is using sudo like this: >>>> >>>> [ Where /etc/sudoers looks like this ] >>>> --- BEGIN /etc/sudoers --- >>>> root ALL=(ALL) ALL >>>> --- END /etc/sudoers --- >>>> >>>> $ sudo vi /etc/hosts >>>> >>>> with 'Primary Administrator' on Solaris you would do this: >>>> >>>> $ pfexec vi /etc/hosts >>>> >>>> A future extension could be to allow picking the exact list of >>>> profiles assigned to the user, but thats a more complex thing to do >>>> during install and requires a lot more time for the user to make >>>> the selection (both of which IMO are a bad thing for the install >>>> experience). >>>> >>> Ok, I will take a look at the Primary Administrator. >>> >>>> If you define a 'System Administrator' RBAC profile there will be >>>> things it can't do so the user might still need to su to root to do >>>> some thing or augment what profiles they have so they can do it in >>>> the future. >>>> >>>> I was going for a compromise between simplicity and security and >>>> taking a lead from what Apple did with MacOS X and how they use >>>> sudo and authoristations (it appears that Apple has an >>>> authorisations like system very similar to Solaris). >>> >>> Ok, fair enough. I have no issue trying to match this. >>> >>>> >>>>>> I think however only one question about this should be asked and >>>>>> we should choose if answering this with a yes means make root a >>>>>> role and given the account "Primary Administrator" rights. >>>>>> >>>>> We haven't talked about giving root a role. We are stating though >>>>> that the account created is a privileged account. >>>> >>>> >>> >>>> That doesn't make any sense. You wouldn't be giving root a role. >>>> You would be *making* the already existing root account a role and >>>> assigning that role to the newly created user. If the user account >>>> that is created has 'Primary Administrator' RBAC rights profile >>>> there is no need to login directly as root (MacOS X does this by >>>> having the root account disabled with no password - making it a >>>> role is the moral equivalent for Solaris) so we should set the root >>>> account to be a role. >>>> >>> Ok, this clarifies how this works. >>> >>>> Again please don't talk about privileged accounts, it isn't really >>>> the terminology we use today. >>>> >>> Ok. >>> >>>> So that you have an idea of what the impact is the result of >>>> selecting this option is trivially this (where alice is the user >>>> just created) >>>> >>>> To give the user the RBAC rights profile: >>>> >>>> usermod -P 'Primary Administrator' alice >>>> >>>> Or just add -P 'Primary Administrator' to the useradd cli when you >>>> create the account. >>>> >>>> To make the root account a role: >>>> >>>> usermod -K type=role root >>>> >>>> If someone can point me to the source I'd be happy to try and add >>>> this functionality into it to show how easy it should be. >>>> >>>> >>>> BTW I really hope you are using usermod(1M) to create the account >>>> rather than trying to hand craft it into /etc/passwd and >>>> /etc/shadow. I also hope that the password is being set by calling >>>> pam_chauthtok(3PAM). >>>> >>> We were planning on using useradd() for adding the user data. And, >>> then add the password data by hand after. The pam stuff isn't >>> something we considered. We would need to take a look at this, how >>> it might work in the miniroot or on first reboot and how we might be >>> able to enable the use of this. >>> >>> Part of my ambiguity on the answers to your comments is that we >>> haven't had the chance to look very closely at this yet. But, you >>> have given us a lot of good data which helps. >>> >>> thanks, >>> sarah >>> _______________________________________________ >>> install-discuss mailing list >>> install-discuss at opensolaris.org <mailto:install-discuss at >>> opensolaris.org> >>> http://opensolaris.org/mailman/listinfo/install-discuss >> >> _______________________________________________ >> install-discuss mailing list >> install-discuss at opensolaris.org <mailto:install-discuss at >> opensolaris.org> >> http://opensolaris.org/mailman/listinfo/install-discuss > > ----- > Gregory Shaw, IT Architect > Phone: (303) 272-8817 (x78817) > ITCTO Group, Sun Microsystems Inc. > 500 Eldorado Blvd, UBRM02-157 greg.shaw at sun.com > <mailto:greg.shaw at sun.com> (work) > Broomfield, CO 80021 shaw at fmsoft.com > <mailto:shaw at fmsoft.com> (home) > "When Microsoft writes an application for Linux, I've Won." - Linus > Torvalds > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/install-discuss/attachments/20070411/9dc06eb1/attachment.html>
