[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.

http://superuser.com/questions/232231/how-do-i-make-sudo-preserve-my-environment-variables

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