[sudo-users] security bug -- sudo undefines functions in environment
Edgar
poll at edgar-matzinger.nl
Tue Aug 5 02:14:36 MDT 2014
Hi,
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\$ '
Or:
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
users).
> 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