[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
*awareness* is the most desirable, first line defense. They implement
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
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
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
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
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
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.
usually used for command completion -- something I don't want turned off
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
most related to command completion. Problems lately have come from
scripts that set flags if something has already been done. Example,
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
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
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
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