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

L. A. Walsh sudo at tlinx.org
Mon Aug 4 17:36:59 MDT 2014

Edgar Matzinger wrote:
> And with 'security functions' you mean bash functions? Strange place
> to enforce security. I truly want to see how and what you're trying
> to do.
    Security is not just about enforcement.  Most security professionals 
lament that
*awareness* is the most desirable, first line defense.  They implement 
hard rules
because people refuse to be aware.

    In the simplest case, -- without typing any commands, I want to
know 1) what computer I am on, 2) where I am at (path indicator), 3) am 
I running
as root?  And I want to know this by looking at the summary line (when 
the window is
closed), as well as when it is open. 

    Now I can be logged in remotely or not -- so knowing what computer a 
command line
is coming from/going to is of basic usefulness to me.  Having some 
indication of my
location gives me context.  I might have 6-8 console windows open at 
once (some may be
minimized).  But as they are minimized, if I want to switch to the 
window open
to the right computer, the right path and right credentials.

    If I can't determine those things by looking -- have to open 
windows, type in
commands... etc. My security has dropped.

    As part of location, I need to know what system I am on.  The 
difficulty of that
varies depending on my hardware and vm's, but at a minimum I print the host
name at the front of the line if I am in a remote session.  No host name 
= localhost.
This means when sudo or pam clears out my host, I have typed the wrong 
into the wrong window.  If indications about who I am have been 
disabled, I may be
logged in as root and not know it -- there are security implications to 

    More to the point though, is why I should have to justify my 
security model
as valid to get a tool that does what it says it will do, and doesn't do 
what I tell
it not to. 

>>    It wouldn't if you had your crucial functions designated read-only.
> I don't care what the user's environment is.
    The functions I have for prompts are installed in /etc.  They are 

>> 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.
> No, it isn't. Because they don't exist outside their environment (in
> my case).
    It usually isn't in my case, as I don't usually have my path 
searching places it shouldn't
be, but I am paranoid.  Whatever *can* go wrong, eventually will.
>>  But if you don't
>> want to be safe and want to allow your executables to be overwritten, then
> Now you're talking about executables. What is it? Bash functions or
> system executables?
    I'm using executables as a term for both.  Shell scripts, functions, 
java, perl, compiled
C/C++.... are all executables and all of them exist on my system.  
Functions are
usually used for command completion -- something I don't want turned off 
as root.
But I also use them for prompts
>>    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,
> If sudo breaks your security model, then sudo isn't the tool for you.
    It didn't used to... and you may be write that this version of sudo 
is no longer needed
in my security model.    It may be I need to fix it and redistribute 
that version to support
my security model.  Logrotate is an example of a tool I have to fix for 
my environment --
since I use it to rotate user owned files as well as root.  It was 
changed to fail if
the userid didn't match what was configured, vs. keeping the uid the 
same -- which
is more useful. 
>>    If your functions are important to your system, why aren't you casting
>> them as read-only?
> I don't need to mark them read-only. In the user's environment, the
> user can do what ever he or she wants. If (s)he switches to a different
> user, they will get a "fresh" environment with nothing, except for a few
> environment variables, remaining from the originating shell.
    Over 100 of the functions I get in my environment come from my 
distro --
most related to command completion.  Problems lately have come from
scripts that set flags if something has already been done.  Example, 
many scripts
know not to redefine functions if a flag indicating functions are 
defined is set.
My distro tried not to overwrite user changes by looking at what flags 
are set.
It tries not to redefine things that it knows it has already defined -- 
a cooperative environment.  But with sudo, and policy dictated one-way, that
causes multiple types of failures -- including DISPLAY and REMOTEHOST being

By clearing half the environment, the functions are zeroed but the flag 
isn't. That's
what is irking me the most, is the environment, which I thought 
"no-reset" meant would
be untouched, is still corrupted and any flags I've set to not reset 
things don't even

I certainly don't mind the ability to prune out specific parts of the 
environment being
available -- but NOT having the ability to say "leave it alone", makes 
for a crippled tool.

I just want the ability to say "hands off" and have that honored -- not 
be told by
someone else that I can't have that because I don't know what I want or
what is best for me.

More information about the sudo-users mailing list