bugtraq - Re: Sudo: local root compromise with krb5 enabled

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Fri, 15 Jun 2007 14:36:11 -0400
From: Ken Raeburn <raeburn@....EDU>
To: Kyle Wheeler <kyle-bugtraq@...oryhole.net>
Cc: bugtraq@...urityfocus.com
Subject: Re: Sudo: local root compromise with krb5 enabled

On Jun 14, 2007, at 11:00, Kyle Wheeler wrote:
> On Monday, June 11 at 06:52 PM, quoth Ken Raeburn:
>> In some MIT applications there was a conscious choice to that
>> effect.  The MIT library's interface for verifying credentials has a
>> flag that can be set to indicate whether it should return success or
>> failure for this specific case.  (Though personally, I think the
>> default should be the more paranoid one, it would be an incompatible
>> break from previous versions.)
>
> Maybe I'm misunderstanding here, but so what? This sounds like the
> equivalent of this:
>
>      My program respects the $ALLOW_ROOT_COMPROMISE environment
>      variable. You may think root compromises are bad, and that the
>      environment variable is ludicrous, and I agree (that "feature"  
> was
>      added before I took over), but if I removed it then that would be
>      an incompatible break from previous versions.

Don't forget, "... and we have a trivial way to turn it off, though  
some programs can't be bothered to use it".

And, as I indicated, in a few environments (including certain parts  
of the environment in which the code was developed), root compromises  
actually aren't considered a problem.

> Just because older programs allowed it doesn't make it sacrosanct.

No, it doesn't.  But backwards compatibility isn't irrelevant  
either.  Both sides were considered in the decision, years ago.  I'm  
not saying we've got the best solution -- just that there were  
reasons we wound up with the more open default and a function to  
tighten it up, rather than the other way around.  Perhaps it's time  
to revisit it -- but the existing code is out there and is in use,  
generally using the APIs correctly...

Ken