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
smime.p7s
Description: S/MIME cryptographic signature
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ macports-users mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
