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
