>> I didn?t find a way to remove the profile "All" or "Basic Solaris
>> User" for a specific user (not role). Systeme wide modification
>> (policy.conf) is not an option. I found 6192137 "need ability to
>> remove individual user authorizations" but I ?m not clear about
>> the status. any hint will be appreciate.
>
> From the CR, there is no one assigned. Customers with service
> contracts can log a service request against it and perhaps
> escalate it.
> Perhaps
> http://opensolaris.org/os/community/arc/caselog/2008/034/
> is what your looking for.
>
I think it is a separate issue from the console user case: assume a
configuration where most users need to get the "Basic Solaris User"
profile as specified in PROFS_GRANTED, as they're allowed to run all
commands. There are, however, a few users or roles who need to be
given a more limited set. The only way to administer this right now
is by giving each and every user individually the "Basic Solaris
User" profile, except for those few individuals that shouldn't get
it. This is administratively busywork, really.
A quite obvious example would be the creation of an administrative
role that is only permitted to run a small number of commands (to
manage one specific service), without being able to run all the other
commands that exist on the system.
Implementing some mechanism that removes a complete rights profile
from a user's aggregated set of profiles seems quite hard: what
happens with chained profiles, how to handle a removal of a profile
that wasn't granted but that overlaps with the set as it is at the
point of removal; how to handle removal of a set that is yet to be
added; etc.
However, instead of adding and removing from the set of profiles just
having the ability to specify a "complete set of profiles" for a
given user, i.e. a set that are is augmented by what's specified in
PROFS_GRANTED, would seem to be quite manageable.
e.g. on a given system we'd have:
/etc/security/policy.conf
(...)
PROFS_GRANTED=Basic Solaris User
(...)
and we have two users (jruser, who is a normal user, and limuser, a
user with a limited set of profiles)
/etc/user_attr
(...)
jruser::::profiles=Some Profile, Some Other
Profile;lock_after_retries=yes
limuser::::only_profiles=Profile X, Profile Y
(...)
When these users run "profiles" they'd see:
jruser:
$ profiles
Some Profile
Some Other Profile
Basic Solaris User
All
$
limuser:
$ profiles
Profile X
Profile Y
$
An alternative could be to make use of the "masking" behaviour of
execution profiles: an item listed earlier in the list masks any
later addition, so in the above example if "Profile Y" has:
Some Other Profile:solaris:cmd:::/opt/example/bin/foo:privs=all
we could stop "limuser" from running it with these attributes by
specifying, in "Profile X":
Some Other Profile:solaris:cmd:::/opt/example/bin/foo:
but this would not prevent that user from running /opt/example/bin/
foo altogether, and so it's not useful to prevent All ("*") from
taking effect. Hence, it would be nice if some ability was added that
disallows execution of a specified command altogether.
However, using this feature to configure limited administrative
commands would not be the right approach, but I can see such a
feature be useful as a way to tweak pre-existing rights profiles:
e.g. we could ship an "Operator" profile that consists of
"profiles=Custom Operator,Printer Management,Media Backup,All". The
"Custom Operator" profile would be empty, available for modification
locally, in which they could mask out certain commands -- without the
need to create a replacement Operator profile or modifying a profile
that may be changed in a patch or update.
Just to complete the picture: the ability to remove authorisations
would be useful as well, though for creating limited users/roles that
would not be appropriate either. I'll expand on this in a later
mail; time for dinner now.
Bart
