[sudo-users] security bug -- sudo undefines functions in environment
L. A. Walsh
sudo at tlinx.org
Tue Aug 5 19:35:45 MDT 2014
Edgar wrote:
>
> PS1='\u@\h:\w\$ '
> You can also use PROMPT_COMMAND.
Too limted.
I have something like:
read _CRST <<<"$(tput sgr0)" #Reset
read _CRed <<<"$(tput setaf 1)" #Red
read _CBLD <<<"$(tput bold)" #Bold
declare _prompt_open="" _prompt_close="" _prompt=">"
declare _disp_port=${DISPLAY/[^:]*:/}
printf -v qUSER "%q" $USER
typeset -x qUSER
[[ $UID -eq 0 ]] && {
_prompt_open="$_CBLD$_CRed"
_prompt="#"
_prompt_close="$_CRST"
}
PS1='\['"$_prompt_open"'\]$(spwd "$PWD"
)'"$_prompt"'\['"$_prompt_close"'\] ';
if [[ -n ${REMOTEHOST:-""} ]]; then
function titlebar { \
printf "\033]1;${qUSER}@${HOSTNAME}:%q\007" "$(spwd "$PWD")" ;\
}
export -f titlebar
PS1='\[$(titlebar)'"$_prompt_open"'\]${HOSTNAME}:$(spwd
"$PWD")'"$_prompt"'\['"$_prompt_close"'\] '
fi
--------------
The swpd function is a bit complicated as it adjusted how much it shows
based on screen width and how long the prompt is:
if [[ ! ${qUSER:-""} ]]; then
printf -v qUSER "%q" $USER
export qUSER
fi
export _home_prefix=${HOME%/*}/
#next func idea came from suse, but the code became a complete rewrite
# return a shorted path when displayed path would take up > 50% width of
screen
alias int=declare\ -i _e=echo _pf=printf exp=export ret=return
exp __dpf__='local -a PF=(
"/$1/$2/$3/../\${$[$#-1]}/\${$#}"
"/$1/$2/../\${$[$#-1]}/\${$#}"
"/$1/../\${$[$#-1]}/\${$#}"
"/$1/../\${$#}"
".../\${$#}"
"..." )'
function spwd () { \
(($#)) || { _e "spwd called with null arg"; return 1; }; \
int w=COLUMNS/2 ;\
( _pf -v _p "%s" "$1" ; export IFS=/ ;\
set $_p; shift; unset IFS ;\
t="${_p#$_home_prefix}" ;\
int tl=${#t} ;\
if (($#<=6 && tl<w));then ((tl<=2)) && \
{ _e -En "${_p}";return 0; } ;\
else
\
eval "$__dpf__" ;\
int i pfl=${#PF[*]} ;\
for ((i=0; i<pfl; ++i)); do eval \
"_pf -v _pa %s \"${PF[i]}\"" ;\
_p="$(eval "_pf %s \"$_pa\"")" ;\
((${#_p}<w)) && break; done ;\
fi
;\
_e -En "${_p#$_home_prefix}" )
}
---
the PF are the various "short forms" of the prompt that
get tried based on space.
The PS1 prompt also sets my Terminal title w/current dir so I can
know what window is open to what dir when all are minimized.
>> a command line
>> is coming from/going to is of basic usefulness to me. Having some
>> indication of my
>> location gives me context.
> Now I can be logged in remotely or not -- so knowing what computer
>
> True. Rebooting the wrong host....
> I wonder if it is possible at all to create a breadcrum trail.
---
Have rebooted wrong system. Not fun, but not fatal... just a pain.
>
> 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.
I do...
> In my eyes, security is something else. But you're correct that
> it is easier to make mistakes.
---
Security is about information integrity as well as protection.
Even windows has implemented integrity labels.
>
>> 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.
----
IF REMOTEHOST is set... when sudo gets run.. that is cleared by default
on my system.
In fact, I had to setup REMOTEHOST and DISPLAY in pam_env... which
some are now using "mid-session" to reinit the env -- which hoses
REMOTEHOST and DISPLAY usually -- since they are only available at
initial remote access.
>
>> 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.
----
I have scripts and executables in my bin dir. I write little in
C/C++ these days...
>
>
>
>> 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.
---
No,... like set an envvar readonly to indicate that env-read-only
functions are defined... they both propagate the same way.
(aliases don't though)...
>
>> My distro tried not to overwrite user changes by looking at what
>> flags are set.
>
> Something, you've developed yourself I gather?
----
Well my own user changes, yes, but I worked with the distro folks to
make
sure they didn't overwrite my changes... I try to layer mine on top of
theirs...
>
>
>> 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.
----
Yeah, but the way my distro had pam_env setup, it cleared them by
default...
especially the re-running of pam_env... when the remote stuff wasn't
available.....ug...
>
> Kind regards, Edgar Matzinger.
> _
ditto... & cheers!
linda
More information about the sudo-users
mailing list