Bart,
In general I don't think that the existing RBAC implementation is the
right architecture for implementing restrictive environments. The
original goal was to configure administrative roles, not to confine
ordinary users. However, I agree with your suggestion making it
configurable whether the values of AUTHS_GRANTED and PROFS_GRANTED are
appended to the respective lists. The keyword use_defaults may be
misleading since all the rest of the default in policy.conf would still
apply.
A more extensible approach would be a list of which default settings to
ignore, e.g.
ignore_defaults=auths,profs
however, right now I can't see any other defaults currently in
policy.conf that should be ignored.
The FMAC project, http://opensolaris.org/os/project/fmac/ , is
specifically goaled to address the issue of restricting the individual
applications that a user can execute, and what resources those
applications have access to. I think that any further enhancement to
the existing RBAC implementation should take into account how it could
be merged with the evolving FMAC architecture. Ultimately we want to
combine these two implementations in a compatible way so that the
customer can benefit from both features.
--Glenn
Bart Blanquart wrote:
> With the current implementation of getexecuser(3SECDB) and friends it's
> only possible to list commands that a user can execute -- there's no
> possibility to deny one or more commands.
>
> To be honest: it's possible to create a subset but that entails listing
> all possible commands that are permitted rather than just denying a
> smaller list, so is pretty painful administratively.
>
> The default rights profile "Basic Solaris User" assigns a wildcard
> entry, so all users are granted the right to execute pretty much any
> command (as long as they have the file permissions to do so).
>
> With that in mind it's obvious that creating one or a few restricted
> accounts isn't easily done: editing policy.conf(4) and removing the
> PROFS_GRANTED entry also means that each (normal) user needs to be added
> to user_attr(4) and be granted that basic profile again.
>
> One way of addressing this could be by creating an option to not use the
> defaults (so in user_attr(4) the user's entry would have a
> "use_defaults=no") which would make only the auths= and profiles=
> entries in user_attr(4) apply.
>
> It's quite low impact: a quick glance through the code seems to say two
> one line changes would suffice, adding a check for that key-value pair:
>
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libsecdb/common/chkauthattr.c#60
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libsecdb/common/getexecattr.c#269
>
> Another approach could be to permit dropping profiles from a list, maybe
> by adding them to a profiles= entry but preceded with a minus sign. This
> would make most of the profile-parsing code a bit more complex, as all
> profiles need to be traversed to check if any are dropped before the
> profile contents are used.
>
> A third approach would be creating special exec_attr(4) entries that
> imply a denial rather than permission. Implementing this seems
> potentially quite complex, though less so than dropping profiles as the
> sequence of exec_attr(4) entries already matters today: the first
> matching entry in a user's set of profiles is used even if a more
> powerful (or more appropriate) entry exists further down the list.
>
> A different 'type' of exec_attr(4) entry could be created (so that
> besides "act" and "cmd" there is one that implies denial), though
> reconciling the ordering of two different types of entries might prove
> tricky as getexecuser(3SECDB) and friends are meant to list one type or
> all types.
>
> For "cmd" type entries the 'id' for denials could be changed so it
> starts with a minus sign. Both getexecuser(3SECDB) and
> getexecprof(3SECDB) would then need to match both "id" and "-id", and
> matchexecattr(3SECDB) would need to consider finding "-id" to be
> equivalent to not finding a matching entry.
>
> This does have the downside that it assumes that matchexecattr(3SECDB)
> is being used against the complete set of applicable profile entries,
> neither of which are guaranteed to be the case...
>
> While I like the idea of having one syntax that can drop profiles
> (approach #2) or execution profile entries (#3) seen that implementing
> those might be non-trivial in the shorter term the ability to disable
> defaults for specific accounts might be best, maybe combined with
> updating the documentation to reserve leading minus signs and mandating
> the use of matchexecattr(3SECDB) or when parsing entries manually to
> account for the possibility of negating entries.
>
> Thoughts & comments welcome.
>
> Bart
> _______________________________________________
> security-discuss mailing list
> security-discuss at opensolaris.org
>
