The way this is addressed in Trusted Extensions is that the Fail Safe login option is modified to present an su command. If you are authorized to assume the root role, and you enter the root password, you have a root terminal, even if you're normal login would fail. For example, in TX, normal user's can start arbitrary processes in the global zone as themselves, but they can still do a Fail Safe login into the global zone and su to root.
However, TX doesn't currently handle the similar case of a command line login (which has no failsafe option). --Glenn 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 > > > >------------------------------------------------------------------------ > >_______________________________________________ >security-discuss mailing list >security-discuss at opensolaris.org > >
