[sudo-users] security bug -- sudo undefines functions in environment

[L. A. Walsh]

Edgar wrote:
> Hi Todd,
>
> On 2014-08-04 08:11, L. A. Walsh wrote:
>> Todd C. Miller wrote:
>>>
>>> I'm sorry if it causes problems for you but the behavior is not
>>> going to change.
>>>   ----
>>   Can you explain why it shouldn't be configurable?
>
> And breaking the security model?
----
    Breaking "the" security model?  It already is breaking its own
security model, not to mention that sudo shouldn't be dictating the
one-true-security model to all users & sites.  Anytime you start
arguing for the "one-true-security model" as being the only thing
you support, you have to realize it isn't going to work for everyone.

    Consider that the way it is now, it violates it's own security model.
Either the environment is reset or it is not.  But that's not what sudo does
now.  It fully resets it, or it does so half way.

    Did you notice the error in my original post.

    sudo **halfway** undefined the spwd function.  It removed the
content, but left it "read-only" -- which means it cannot be replaced
or reset. 

    Sudo disables all security functions and prohibits re-installing them.

    That's going way overboard in terms of how it dictates its belief
in how security should be.  If the sys admin says "don't reset the 
environment",
how is resetting random parts of it justified?


> In my case, I've set up a
> standard set of functions which are sourced with every shell
> that's started. Of course, a user can load their own version
> of those functions, but switching to a different user using
> sudo reloads *the default set of functions*! Furthermore,
> the prompt is always reset to the default setting. And thus,
> always operates (as designed).
----
    It wouldn't if you had your crucial functions designated read-only.
Allowing users to overwrite and insert their own versions of system-wide
functions would be like allowing them to copy their own versions of
login, cat, or kernel modules into the executable.  But if you don't
want to be safe and want to allow your executables to be overwritten, then
you don't need to flag them as read-only.  In which case, sudo will wipe
them out and DISALLOW them being reset.

    And this is your security model?   This is why I say don't force your
security model on others, since having only one security model means
when sudo breaks your security model, it will break all of them, but if
it stayed within the constraints of NOT resetting the environment, it 
wouldn't
be resetting data that is can be functional.

>
> In your case, you could always go back to version 1.6.8p2 of
> sudo. But, I wouldn't recommend it. Your users could also source
> their version of those functions and other settings after doing
> sudo.
----
     I'd be more likely to release an alternate version of sudo like others
have of login, tar, and other OS components -- going backwards is not
usually a great idea.

    If your functions are important to your system, why aren't you casting
them as read-only?  Do you allow users to overwrite other executables?
(not that either restriction can't be gotten around by a determined user).