Hi Dave.
Thanks for taking a look.
On 03/29/11 16:00, Dave Miner wrote:
Jack, a couple of comments on the RBAC-related portion here:
usr/src/cmd/rbac/prof_attr.system%2Finstall%2Fauto-install
usr/src/cmd/rbac/user_attr.system%2Finstall%2Fauto-install
1. Is it necessary for some reason to define aiuser as a role for root?
I pulled that out, since root can do anything it wants and doesn't need
explicit permission to execute as aiuser.
Currently all that is now in user_attr is:
aiuser::::type=role;profiles=AIuser,Stop
(Note: Round-2 code review just went out.)
Originally I thought defining aiuser as a role for root would be useful
to document the root<->aiuser relationship, but thought about it more
and decided it was more confusing than helpful.
2. Won't it work to just place the auths that are in the profile
you've created directly on the aiuser user? If so, we can dispense
with the separate role.
Yes, it seems to work fine without the role.
3. I'm wondering if using the Stop profile is a good idea here. It
would seem to inhibit automatic inheritance of default
authorizations/profiles from a standard user environment, meaning we'd
have to be more aware of changes elsewhere in the system and have to
fiddle with this more often.
It is true that if changes to the Basic User profile were made that we
might have to add them to the AIuser profile. However, we may want to
pick and choose which new privileges to grant to the AIuser anyhow.
There are currently some given by the Basic User profile which are not
necessary and so are not given to AIuser. (The Stop profile disallows
these things from being enabled.) Some examples are running the profile
manager, sending mail, mounting removable devices and doing some usb
administration (not sure about the last one, it is
solaris.admin.wusb.read). So even though the profile is called "Basic",
these privileges are not always required.
However, the most basic privileges are granted to everyone (see
privileges(5)), and that alone is almost enough for AIuser. I don't see
the need to allow the AIuser to take on the Basic Solaris User profile.
Conceptually, I believe aiuser is essentially a normal user with some
elevated read privileges, which is what you've defined with the auths
Yes and no. Here's a summary of AIuser's privs:
- AIuser can do things that unprivileged users can do.
- The Basic Solaris User profile, enabled by default, is not enabled
because of the Stop profile.
- The AIuser profile adds reading of network configuration and SMF
properties.
(I'm wondering if there are more we need there, actually, but don't
have specific suggestions).
I used Stop to disable Basic Solaris User because I was told to tightly
restrict AIuser. What it really boils down to is this:
- Is it worth sacrificing restricting stuff like mounting removable
devices in exchange for more maintainability (by not using Stop)? Maybe
a little, but we still get the benefit of restricting the AIuser more
tightly.
- By using Stop we decouple the Basic Solaris User from AIuser. This
allows for finer granularity of control since adding something to the
Basic Solaris User doesn't automatically add it to the AIuser. Having to
add something to AIuser because it is added to the Basic Solaris User is
not what we want. This finer granularity is worth the small sacrifice in
maintainability.
(And besides, there are not very many items listed in Basic Solaris
User's profile so it isn't likely to require many changes in the
future.)
I consulted with someone on the RBAC team about this configuration
before finalizing it, and he helped me come up with this.
So it still seems cleanest to me to decouple using Stop, even though we
may have to add something occasionally to the AIuser if it gets added to
the Basic Solaris User and is deemed necessary for the AIuser to have.
Hopefully this email didn't get too wordy... Please reply if this
doesn't make sense or you want to discuss it further.
