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 > > 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 > http://opensolaris.org/mailman/listinfo/install-discuss
