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

Edward Capriolo edlinuxguru at gmail.com
Mon Aug 4 10:05:21 MDT 2014

It seems like you have full control over what you would want to reset.


It is hard to expect sudo to "do the right thing" in the face of bash
environment variables. Sudo only as secure as the binaries/shell scripts
the users execute with it.

On Mon, Aug 4, 2014 at 12:01 PM, L. A. Walsh <sudo at tlinx.org> wrote:

> 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).
> ____________________________________________________________
> sudo-users mailing list <sudo-users at sudo.ws>
> For list information, options, or to unsubscribe, visit:
> http://www.sudo.ws/mailman/listinfo/sudo-users

More information about the sudo-users mailing list