> This project proposes updates to the rbac implementation.
>
> Release binding: minor.
>
> The current rbac implementation has several shortcomings:
The project team doesn't say why these are shortcomings.
I was having a hard time getting the motivation. Fortunately
in an offline discussion today, it was pointed out that
the particular use model was for a "kiosk user" model and that
the intent was to explicitly define specific user accounts
that would be restricted as an exception to the architecture
introduced when RBAC was introduced.
Given that I too am happy with the case (+1), but have a few nits
with the specification that I'd like acknowledged.
> - it's not easy to override the default privileges
> defined in /etc/security/policy.conf
>
> - every user *always* inherits whatever is specified in
> /etc/security/policy.conf: AUTHS_GRANTED, PROFS_GRANTED
And the "console owner" gets the CONSOLE_USER.
> To fix these problems, this fasttrack defines the following new
> features:
>
>
> The prof_attr(4) database supports two new keywords:
> defaultpriv, limitpriv; they have the same semantics as they
> have in user_attr(4). On establishing a user credential,
> the profiles database is searched and the first match for
> each keyword is returned.
There is nothing inherent in this proposal that will stop
getting other keywords. In particular audit_flags as
specified in PSARC/2010/003, EOL and removal of audit_user(4)
and getausernam(3bsm).
> The new system defined profile "Stop"; when this profile
> is encountered it excludes all the later profiles which would
> normally be encountered. Specifically, if a user has a profile
> in its list which includes "Stop", then the PROFS_GRANTED
> profiles are never considered for this user and the
> AUTHS_GRANTED are ignored.
Additionally if the user is the "console owner", the CONSOLE_USER
profiles are never considered for this user.
Only authorizations seem to be explicitly addressed here. How are
executables addressed? That is the use of pfexec?
Gary..
