Insufficient privileges?

[Bayard Bell]

On 29 Apr 2011, at 02:57, John B Brown wrote:

> Bayard Bell wrote:
>> To quote the last line on --with-exempt from the INSTALL file for sudo:
>> "You should probably use NOPASSWD in sudoers instead."
>> Is your claim that NOPASSWD is in fact dependent on the compile-time value of --with-exempt and that the sudo documentation has this backwards? It seems far more likely that the problem is having rules that are ordered in the expectation that the first rather than the last match is used. The diff between Apple's sudo build and the stock 1.7.0 base from which it was built isn't that considerable, so any code underlying the difference in behaviour you're suggesting really should jump out.
> 
> 	Yes. see 'man sudoers' from the original source.
> "
> Users in the group specified by the exempt_group option are not affected by secure_path.  This option is not set by default.
> "
> "exempt_group Users in this group are exempt from password and PATH requirements.  This is not set by default.
> "
> 
> 	Sort of, DUH!

You seem to have missed the boat here.

As others have shown, there's nothing that Apple has done to prevent these behaviours from being configured in sudoers. In fact, the source distribution of sudo tells you that you really needn't do this to get NOPASSWD behaviour, and, as you've quoted the man page (which is identical to the Apple page), secure_path is a non-default behaviour controlled by sudoers, which means it needn't be a problem in the first place. Neither bit of documentation you've cited indicates that the exempt_group option is the only way to get desired behaviours, just the only way that you don't have to express it in sudoers, which the maintainers of sudo see no reason to prefer.

Here's what Apple list as their changes to sudo:

        <key>OpenSourceModifications</key>
        <array>
                <string>Add BSM auditing support.</string>
                <string>Disable sudoedit.</string>
                <string>Remove login_cap reference from man page.</string>
                <string>Allow admin group by default.</string>
                <string>Fix memberd group resolution.</string>
                <string>Reset timer password on reboot.</string>
                <string>Friendlier warning on first usage.</string>
                <string>Clean the environment.</string>
        </array>

All of Apple's changes are available as open source, including the options they used with configure:

'--with-password-timeout=0' '--disable-setreuid' '--with-env-editor' '--with-pam' '--with-libraries=bsm' '--with-noexec=no' '--sysconfdir=/private/etc/' '--with-timedir=/var/db/sudo' 'CPPFLAGS=-D__APPLE_MEMBERD__'

None of the changes break things in the way you speculate, and there are plenty of replies on this list confirming this.  If you really want to replace Apple's sudo with one using exempt_groups, it's your choice, but nothing you've said substantiates that this is necessary because the stock sudo is broken or insufficient. If you're looking to solve your problem, I hope you will find this useful information.

>> In any case I find it difficult to see why the NOPASSWD behaviour is ever desirable because it makes an account essentially root-equivalent without requiring knowledge of the password. With such a config, you're relying on safety because not so many people are trying to target OS X (i.e. there's safety in relatively small numbers) rather than security in terms of the ability to resist determined attack.
> 
> 	Well, it is there for some purpose. If you don't like it, don't use it. I kind of like it on my little one user box hiding behind three firewalls.

The conventional use case I've encountered for impersonation rules without password requirements is to provide non-shell access to a command that would be a greater security risk if setuid and available to a larger user population. In fact, the internal audit department at a previous job forbid having password-less impersonation rules with shell access to any ID, which seemed to me a pretty reasonable rule of thumb. Providing the NOPASSWD setting to support this kind of behaviour doesn't get one to an inference that it's a good idea to use it for a root shell rule. If you think you can keep all your windows open on your ground-floor home because you've got three locks on the front door and a three-foot tall fence around your garden, that is absolutely your decision, but it's not unreasonable on a list like this to point out that it makes for considerable security risks that others may not wish to accept.

Cheers,
Bayard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1515 bytes
Desc: not available
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20110429/1ee5d89d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 841 bytes
Desc: This is a digitally signed message part
URL: <http://lists.macosforge.org/pipermail/macports-users/attachments/20110429/1ee5d89d/attachment-0001.bin>