Nate Williams wrote:
>> I still think that it is a lot of effort for just one or two
>> programs. xlock and xlockmore (basically the same program) are the
>> only two programs that I'm aware of that need to access the password
>> file and not change the uid of the process. Where are the rest of the
>> half dozen :-)...
screen is one... (although screen has lots of other features which like to
be setuid as well). Again, a lot of the needs for setuid root access for
top can be caught with group permissions and ptyd (previously mentioned
relating to xterm).
>The other issue is since they will no longer be setuid(), someone can
>crash them and get the passwd file from them to crack later or we'd have
>to change all of the 'don't dump core' code to look for setgid(passwd)
>stuff. All of a sudden this 'simple fix' gets to be obnoxious and isn't
>buying us a whole lot.
The program will still be setgid, so the check in the core dump routine
(/usr/src/sys/kern/kern_sig.c) which looks at processes' option flags
for P_SUGID would still result in the same behavior as it had when it
was setuid. If it didn't, this would be a security bug in the core dump
routine, as all setgid programs (ala top) would suffer from the same problem
as you described.
>Setuid is *NOT* evil in all cases, you simply must be careful.
Not in all cases. But in cases where setgid access and appropriate
group permissions suffice, I would prefer to give out limited privilege
than the universal privilege a setuid root program gets.
>The fact
>of the matter is *some* programs must have root priviledges to do their
>job securely and/or at all.
Some do. A lot don't. I'm an advocate of not giving root privs out unless
it is absolutely necessary.
-- William
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message