On Fri, Jul 30, 2010 at 04:51:57PM -0700, David Brodbeck wrote: > > On Jul 30, 2010, at 4:41 PM, Will Fiveash wrote: > > > On Fri, Jul 30, 2010 at 03:49:57PM -0700, David Brodbeck wrote: > >> > >> On Jul 30, 2010, at 3:31 PM, Scott Rotondo wrote: > >>> Regarding the expansion of the attack surface, remember that > >>> assuming the root role requires logging in to a user account first > >>> and then providing the root password. > >> > >> Well, yes and no. It's true that su requires the root password, > >> and sudo usually requires the password of the user account before > >> running commands with root privileges. pfexec does not require any > >> password entry at all, so an account that's allowed to exercise > >> root privileges via pfexec is, from a security standpoint, > >> functionally equivalent to another root account. > > > > No, an account that has to either use su or pfexec to acquire root > > privs is not functionally the same as a root user account. Let's > > assume there are several people that require root privs to do their > > job. With a root user account any of them could login as root and > > audit records would not be able to identify which of those people > > did what as root. With RBAC and root as a role and each admin > > having their own account, audit records would show who became root > > and what commands they executed as root. Accountability is > > definitely enhanced with root as a role. > > Oh, I definitely agree. But I was making that comment in terms of the > ability of an attacker to get root privileges. In that case > compromising any admin account that can assume root privileges via > pfexec is functionally just as good to the attacker as compromising > the root account itself. So every privileged user you add makes the > system slightly more vulnerable to password guessing attacks. That's > what I meant when I said it expanded the attack surface. Of course, > hopefully your admins are all picking good passwords and not leaving > their SSH keys lying around. :)
Making root a role and giving a user a pfexec profile that provides all privs are two different things. It is possible for example to have a user_attr entry that looks like: jimw::::type=normal;roles=root;profiles=Basic Solaris User This allows jimw to su to root which requires root's password but pfexec'ing as jimw doesn't grant him additional privs. One could also configure jimw's user_attr entry to be: jimw::::type=normal;profiles=File System Management,ZFS File System Management which doesn't give jimw the ability to su to root but does give some, but not all, additional privs when he pfexec's commands. -- Will Fiveash Oracle Note my new work e-mail address: [email protected] http://opensolaris.org/os/project/kerberos/ Sent using mutt, a sweet text based e-mail app: http://www.mutt.org/ _______________________________________________ opensolaris-discuss mailing list [email protected]
