Darren J Moffat wrote:
> Scott Rotondo wrote:
>> (a) A unified control mechanism, like the authorizations you propose,
>> should someday replace the settings in service-specific config files
>> to control root logins.
>
> Agreed and this is a step in that direction but it isn't the whole
> picture nor is it the primary reason for doing this.
>
>> (b) The root account should continue to have a simple set of
>> authorizations, like solaris.*, not a long enumeration of auths that
>> excludes solaris.login.console and solaris.login.remote.
>>
>> Meeting those two goals would be difficult unless we introduce a
>> subtractive model for specifying authorizations like we have for
>> privilege sets. Is that the best solution? Or is there any way to
>> recast this proposal to make this future evolution easier?
>
> Bart and I really do want to implement a subtractive model (negative)
> authorizations. This way we could change the default user_attr entry
> for root to be:
> solaris.*,!solaris.login.remote,!solaris.login.local
> So that this would match the behaviour currently implemented by
> /etc/default/login:CONSOLE=/dev/console
>
> We want to address negative authorizations as a separate proposal,
> because it is actually quite complex and we have been trying to get it
> correct for a long time (Bart being the one doing most of the thinking
> on it).
>
> Maybe soon Bart can forward a proposal here for the negative
> authorizations.
>
I'm OK with that direction, and I agree that the negative authorizations
don't need to be part of this project. My reason for raising the issue
is to prompt you (and others reading the email thread) to consider
whether there is any better way to implement this project and position
us to meet the goals above.
If negative authorizations are the best method we can think of, that's
fine with me.
Scott
--
Scott Rotondo
Principal Engineer, Solaris Security Technologies
President, Trusted Computing Group
Phone/FAX: +1 408 850 3655 (Internal x68278)
