Darren J Moffat wrote:
> Garrett D'Amore wrote:
>> Its been a while since I looked at sudo (brain long since rewired to
>> pfexec), but IIRC sudo had some kind of support for kerberos. I
>> don't see any compilation of kerberos in the flags below. Can you
>> provide a one-or-two sentence description of rationale and impact?
>> (I *suspect* I know what the reasonable answers are, but I'd like the
>> answers from the project team directly, and I think it would be good
>> to have the record in the case log.)
>
> sudo's Kerberos and PAM support are compile time mutually exclusive.
> The Solaris pam_krb5 module has been tested with sudo and is known to
> work. Personally I think having to make the choice between PAM and
> Kerberos at compile time is unfortunate but that is how the upstream
> code works. Since Kerberos is not (unfortunately in my opinion) not
> mandatory to use on Solaris PAM is the only sensible choice from that
> mutually exclusive set.
Pretty much what I expected, but pam_krb5 was (to me) a little surprise
bonus.
Just to set my understanding straight: does the pam_krb5 module combined
with sudo's pam support provide full Kerberos functionality? Are there
any feature gaps from sudo's native Kerberos support?
>
>> Second, I notice that the package SUNWsudo is Committed, while
>> everything else is Uncommitted. This may be ignorance on my part,
>> but if the entire contents of the package are Uncommitted, then what
>> value is there in having the package itself be Committed?
>
> The fact that sudo willl always be delivered from the SUNWsudo package ?
But if the path name of the sudo binary can't be relied upon, then what
is the point of knowing the package name? It seems (and really this is
at most a nit) like an empty promise.
>
>> Third, given that this project lacks Solaris auditing features, I'd
>> really like to see an explicit statement of this limitation in the
>> versions of the man pages we ship, perhaps with a recommendation.
>> Something like: "sudo(1M) does not audit activities. Sites that
>> require auditing information might consider using pfexec(1)."
>
> With my ARC hat on I don't think we shouldn't be vandalising upstream
> man pages like this in my opinion. This case is to ship sudo as is
> and the case explictly says so. We don't list all the other things
> that don't do auditing yet authenticate users, for example webmin
> authenticates users but doesn't audit, Apache has modules to
> authenticate unix users and doesn't audit. We didn't change those
> other components documentation to say they don't audit so I don't
> think we should ask this project to to that to the sudo ones.
I humbly disagree that making the problem worse is a good idea.
However, I will defer to the larger ARC majority on the issue.
>
>> Finally, how will an unconfigured sudo installation behave? (More to
>
> The default case isn't actually unconfigured. This case ships the
> default /etc/sudoers file (in the materials dir).
>
> The default sudoers file only allows root to use sudo.
It was the contents of the default sudoers file I was after. It sounds
to me like this doesn't necessarily represent any more of a backdoor for
auditing than, say, the /bin/sh does. Thanks for the clarification.
>
>> the point, will the "default" installation of sudo create a hole in
>> the auditing infrastructure, for sites that care to have auditing
>> information preserved?)
>
> Auditing is off by default on Solaris and because of the default
> sudoers file I don't believe that is an issue.
>
> Note that using sudo *will* still cause audit records to be written
> and the will still have the correct audit id in the records (because
> sudo doesn't do anything to change that - and shouldn't either). It
> is still possible to get audit records of what commands were executed
> and what their arguments were using the ex class. The only real
> missing part of Solaris audit integration is the equivalent of what
> pfexec does as application level auditing which is in addition to the
> syscall auditing. Personally I don't think that is much of a big deal.
I'm happy with the answers supplied, modulo small disagreement over the
man page issue. However, I'm definitely willing to stand aside and hold
my nose on that issue if the other ARC members are as well.
<not this case>
One of the clarifications I'd like to see from the gang-of-four is
guidance for how we handle cases like this, where the familiarity
benefits directly conflict with Solaris technological superiority.
(E.g. sudo versus pfexec.) From a marketing standpoint, it seems like
we should do what we can to push Solaris users towards technologies that
are optimized for Solaris when we can. There are very few opportunities
(IMO) to do that for users of familiarity commands like sudo, and
product documentation seems like one of the opportunities we could be
taking better advantage of. (Put another way, if someone comes from
linux land, and is used to sudo, once they start using it, how do they
ever learn about the existence of pfexec, or even that there may be
something better than sudo. Some might argue that if sudo works well
enough the user, then why should he look further. I think though, that
if we really want to increase uptake we need to avoid missing
opportunities to point out areas where Solaris can offer superior
functionality to its competitors.)
</not this case>
- Garrett
