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

Edgar poll at edgar-matzinger.nl
Tue Aug 5 02:14:36 MDT 2014


On 2014-08-05 01:36, L. A. Walsh wrote:
> 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.

Enforcement afterall.

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

PS1='\u@\h:\w\$ '
You can also use PROMPT_COMMAND.

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

True. Rebooting the wrong host....
I wonder if it is possible at all to create a breadcrum trail.

  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.

For this case, I set the hostname, userid and CWD in the title of
an xterm.

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

In my eyes, security is something else. But you're correct that
it is easier to make mistakes.

> This means when sudo or pam clears out my host, I have typed the wrong 
> commands

In /etc/bashrc I always set the prompt: PS1='\u@\h:\w\$ '
You can even set it to something like this:

PS1='${REMOTEHOST:-$(hostname -s)}->\u@\h:\w\$ '


PS1='${REMOTEHOST}${REMOTEHOST:+->}\u@\h:\w\$ '

The last one prints the contents of REMOTEHOST and an arrow
if REMOTEHOST is set. And nothing if not.

>    I'm using executables as a term for both.  Shell scripts,
> functions, java, perl, compiled

Whence the confusion. For me, executables are scripts and compiled
source code files located in a 'bin' directory.

Bash functions are functions local to that shell. Even if they
are exported.

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

Well, I use functions to wrap system commands to perform actions
before or after the real command.

> But I also use them for prompts

Bash has powerfull prompts with lots of escaped special characters.

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

Then you were using a very old version of sudo.

> in my security model.    It may be I need to fix it and redistribute
> that version to support
> my security model.

Or adjust your security model.... Just joking.

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

Huh? Logrotate is started from cron using 'root' and as such
can switch to any user defined on the system (including LDAP

>    Over 100 of the functions I get in my environment come from my 
> distro --
> most related to command completion.

And are reloaded everytime bash starts (in my environment).

>  Problems lately have come from
> scripts that set flags if something has already been done.

And with flags you mean files? The standard or default command
completion files in /etc/bash_completion.d do not set flags to
indicate something has been done.

> My distro tried not to overwrite user changes by looking at what flags 
> are set.

Something, you've developed yourself I gather?

> causes multiple types of failures -- including DISPLAY and REMOTEHOST 
> being

Those can be added to sudoers to be included in the list of
variables to be propagated.

Kind regards, Edgar Matzinger.

More information about the sudo-users mailing list