LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 09-14-2011, 03:57 PM   #1
KuimFieg
Member
 
Registered: Sep 2011
Location: France
Distribution: Debian Squeeze
Posts: 32

Rep: Reputation: Disabled
PATH, functions and security. Bash scripting best practices.


Hello all.
I've been using linux for a few years and really enjoy it. I'm a self learner.
I have written and am using quite a few home made scripts for different purposes. I sometimes come across bash scripts where commands are called via there full paths only.

For instance "ls" becomes :
Code:
LS="/bin/ls"
$LS /whatever/folder
I was wondering if there was a valid reason for this and what is it in detail. I guess the idea is to prevent PATH override but if a potential attacker has the ability to mess with you PATH variable, your system is already compromised so is this really worth it?

Further more, if this is really on issue, what about overriding commands with functions?

For example, this is what I get on Debian Squeeze:
Code:
 user@sys:~$ cp --version
 cp (GNU coreutils) 8.5
 Copyright (C) 2010 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.

 Written by Torbjorn Granlund, David MacKenzie, and Jim Meyering.
 user@sys:~$ cp() { echo "overriden"; }
 user@sys:~$ cp mbox mbox.bak
 overriden
Or worse :

Code:
 user@sys:~$ /bin/ls --version
 ls (GNU coreutils) 8.5 
 Copyright (C) 2010 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
 This is free software: you are free to change and redistribute it. 
 There is NO WARRANTY, to the extent permitted by law.
 
 Written by Richard M. Stallman and David MacKenzie.
 user@sys:~$ /bin/ls() { echo "cracked you!"; }
 /bin/ls() { echo "cracked you"; }
 user@sys:~$ /bin/ls -l
 cracked you
So is this really something to keep in mind when writing scripts. What are the "best practices"?
I've never seen any recommendations on that matter.

As I said my view is if a potential attacker can do this sort of thing, it's already too late. What do you think? Am I missing something ?

Last edited by KuimFieg; 09-22-2011 at 03:06 PM.
 
Old 09-14-2011, 04:11 PM   #2
macemoneta
Senior Member
 
Registered: Jan 2005
Location: Manalapan, NJ
Distribution: Fedora x86 and x86_64, Debian PPC and ARM, Android
Posts: 4,593
Blog Entries: 2

Rep: Reputation: 326Reputation: 326Reputation: 326Reputation: 326
Full paths aren't to protect against attacks, they're used to protect against users.

For example, if a user creates a script or alias for 'ls', but hard-codes an option or number of parameters, another script invoking the user's 'ls' may fail or return incorrect results.
 
Old 09-14-2011, 04:16 PM   #3
SL00b
Member
 
Registered: Feb 2011
Location: LA, US
Distribution: SLES
Posts: 375

Rep: Reputation: 111Reputation: 111
Well, I'm not going to comment on industry practices, but I know why I use fully-qualified paths.

1) When I'm going to run my script from cron or init.d. Since these won't be launched by my shell, I can't presume my path will be valid. If I code the fully-qualified path, I know the script will work.

2) When I want the script to run against the correct directories no matter where I happen to be in the tree. This would be for commands that aren't in my path by design, input or output files, etc.

In other words, it's all about functionality. It has nothing to do with security.
 
Old 09-14-2011, 04:50 PM   #4
KuimFieg
Member
 
Registered: Sep 2011
Location: France
Distribution: Debian Squeeze
Posts: 32

Original Poster
Rep: Reputation: Disabled
@macemoneta, ok I had not thought about aliases but I've just tested this on my system and PATH has precedence over user aliases.

@SL00b, PATH is defined /etc/crontab on my system, so this wouldn't be an issue. I realise one can also redefine the PATH variable at the beginning of a script.

I recall reading a while ago (can't remember where/who/what) that certain sysadmins wouldn't set PATH in order to prevent command overrides at the command prompt and forcing the users to invoke programs/scripts only via full paths. I guess there is a certain school of thought there, but thinking about it I realised this sort of practice is ineffective anyways.
 
Old 09-15-2011, 04:52 AM   #5
Reuti
Senior Member
 
Registered: Dec 2004
Location: Marburg, Germany
Distribution: openSUSE 11.4
Posts: 1,319

Rep: Reputation: 252Reputation: 252Reputation: 252
Quote:
Originally Posted by macemoneta View Post
Full paths aren't to protect against attacks, they're used to protect against users.
Yep, and to have an option to adjust a script to the actual environment. Assume you have a script having:
Code:
MAKE=make
ECHO=echo
on AIX but you need the gmake instead, as the original make is different on AIX. In addition you don’t want any output during the build process. You can adjust:
Code:
MAKE=gmake
ECHO=:
Nevertheless, when you read the script you know exactly what the author intended to do when you see $MAKE and $ECHO. It’s more readable than having $PGM1, $PGM2 there.
 
Old 09-16-2011, 05:54 AM   #6
Trickie
Member
 
Registered: Sep 2004
Posts: 38

Rep: Reputation: 23
Some commands, using the same name, exist both as bash built-in commands, and standalone tools which usually reside in /usr/bin; "echo" is one example of this. One may prefer, for various reasons, *not* to use the bash built-in, in which case the absolute path name must be used in order to differentiate between the two.

Richard
 
1 members found this post helpful.
Old 09-17-2011, 02:17 PM   #7
zek
LQ Newbie
 
Registered: May 2007
Distribution: Fedora
Posts: 4

Rep: Reputation: 1
Note however that the standalone tool will execute much slower than the built-in. Be mindful when writing loops.

Code:
$ time for i in {1..5000} ; do /bin/echo > /dev/null ; done 

real	0m8.465s
user	0m1.762s
sys	0m6.676s
$ time for i in {1..5000} ; do echo > /dev/null ; done 

real	0m0.169s
user	0m0.105s
sys	0m0.064s
 
1 members found this post helpful.
Old 09-19-2011, 08:34 AM   #8
LQParsons
LQ Newbie
 
Registered: Feb 2010
Location: North of Boston, Mass (North Shore/Cape Ann)
Distribution: CentOS 6.0
Posts: 21

Rep: Reputation: 0
path to command to override other alias

Hi.
A common reason, in addition to the other ones given, to create a 'full path' in your script is sometimes a system administrator will have already redefined a command in a system .rc
For instance, said person thinks that removing a file should always be confirmed, so in a system file redefines for you:
Code:
  $ alias rm='rm -i'
now you, in your script, want to remove a file, so you do the normal
Code:
  
$ rm filename

#
# and get instead ...
#
$ rm -i
By defining commands in your shell script, you get what you ask for.

btw, when I think certain commands should not be used, I make a new command name, such as
Code:
$ alias rmi='rm -i'
that way I get what I want and I don't screw up folk who disagree with me.

Enjoy.
-doug

Last edited by LQParsons; 09-21-2011 at 09:44 AM. Reason: correcting formatting errors
 
Old 09-19-2011, 09:01 PM   #9
chrism01
Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.5, Centos 5.10
Posts: 16,269

Rep: Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028
Although all processes have an idea of PATH, the content may not be what you want eg cron deliberately sets a minimal or non-path, because it can be invoked by any user for any purpose, so the less 'assumptions' the better.
Note also that on some systems you may have multiple 'versions' of a cmd eg on Solaris there are binaries derived from Unix System V and some from the UCB (Berkely; see *BSD systems).
cron is a basic tool on all *nix.
As above, aliases come into play, as do symbolic links ....

One thing I always do for prodn scripts is to specify the shebang line eg '#!/bin/bash' as otherwise it will be called via the default shell of whatever env it happens to be in...
 
1 members found this post helpful.
Old 09-20-2011, 04:00 AM   #10
Reuti
Senior Member
 
Registered: Dec 2004
Location: Marburg, Germany
Distribution: openSUSE 11.4
Posts: 1,319

Rep: Reputation: 252Reputation: 252Reputation: 252
Quote:
Originally Posted by chrism01 View Post
One thing I always do for prodn scripts is to specify the shebang line eg '#!/bin/bash' as otherwise it will be called via the default shell of whatever env it happens to be in...
Good note: where is the default shell defined? Even when I change my interactive shell with chsh to be csh and login again, scripts are still interpreted by the bash on openSUSE (ones without the shebang). Where is it defined?
 
Old 09-20-2011, 09:25 AM   #11
archtoad6
Senior Member
 
Registered: Oct 2004
Location: Houston, TX (usa)
Distribution: MEPIS, Debian, Knoppix,
Posts: 4,727
Blog Entries: 15

Rep: Reputation: 231Reputation: 231Reputation: 231
KuimFieg & LQParsons,

Welcome to LQ. I hope your time here helps you as much as mine has helped me.

In order to help us better help you, please put code, command line output, config files, etc. inside [CODE] tags, aka "Code:" blocks.
In case your're not familiar with them, there are 2 ways to generate "Code:" tags:
  1. You can simply type them yourself -- "[code] ... [/code]". (They are not case sensitive.)

  2. You can also click on the '#' icon above the text entry window. If you highlight the code, command line output, config files, etc. before you click the '#' icon, your code will get put inside a "Code:" block. The '#' icon is available when you start your post by clicking the "Post Reply" button or use the "Go Advanced" button under the Quick Reply window; it is not currently available in the Quick Reply window itself.

The [CODE] tags will make your posts easier to read, & that will get you more, faster, better answers. -- Again, help us help you.
BTW, You can edit your post(s) to do this retroactively. Please do so soon.

Thank you, & for the 2nd time, welcome.
 
Old 09-22-2011, 04:16 PM   #12
KuimFieg
Member
 
Registered: Sep 2011
Location: France
Distribution: Debian Squeeze
Posts: 32

Original Poster
Rep: Reputation: Disabled
Thanks for all the answers. I wasn't really aware of bash built-ins being faster.

Quote:
Originally Posted by LQParsons
For instance, said person thinks that removing a file should always be confirmed, so in a system file redefines for you: ...
By defining commands in your shell script, you get what you ask for.
I don't think this is correct since:
Code:
alias rm='rm -i' && echo -e '#!/bin/bash -x\nrm "$1"' > rm_test.sh && chmod 755 rm_test.sh && touch remove_me && ./rm_test.sh remove_me
Returns : "+ rm remove_me". It seems aliases are accessible only via interactive shells

Quote:
Originally Posted by Reuti View Post
Good note: where is the default shell defined?
If you have a local account:
Code:
user@sys:~# grep $(id -un) /etc/passwd
user:x:1000:1000:Gecos:/home/user:/bin/bash
 
Old 09-22-2011, 04:58 PM   #13
Reuti
Senior Member
 
Registered: Dec 2004
Location: Marburg, Germany
Distribution: openSUSE 11.4
Posts: 1,319

Rep: Reputation: 252Reputation: 252Reputation: 252
Quote:
Originally Posted by KuimFieg View Post
Code:
user@sys:~# grep $(id -un) /etc/passwd
user:x:1000:1000:Gecos:/home/user:/bin/bash
This is the login shell, but not the one used to interpret the scripts. Example:
Code:
$ ssh pc15370
Last login: Thu Sep 22 23:27:44 2011 from blabla
Have a lot of fun...
reuti@pc15370:~> getent passwd reuti
reuti:x:1000:100:Reuti:/home/reuti:/bin/bash
reuti@pc15370:~> chsh
Changing login shell for reuti.
Password: 
Enter the new value, or press return for the default.
	Login Shell [/bin/bash]: /bin/tcsh
Shell changed.
reuti@pc15370:~> getent passwd reuti
reuti:x:1000:100:Reuti:/home/reuti:/bin/tcsh
reuti@pc15370:~> exit
logout
Connection to pc15370 closed.
$ ssh pc15370
Last login: Thu Sep 22 23:27:54 2011 from blabla
Have a lot of fun...
/home/reuti> echo $SHELL
/bin/tcsh
/home/reuti> cat where.sh
pstree -u reuti
/home/reuti> chmod +x where.sh 
/home/reuti> ./where.sh
sshd───tcsh───sh───pstree
There is a sh popping up in the process chain. So the question is still there: if there is no shebang, where is it defined which shell will be used to interpet the script?

While I think about it: the shell will fork, the forked process will call execvp or alike. And indeed there inside they use the defined _PATH_BSHELL constant (defined in paths.h as /bin/sh). So it’s hardcoded in glibc.

I leave it here, in case someone wonders about it too.

Last edited by Reuti; 09-22-2011 at 04:59 PM.
 
Old 09-23-2011, 12:39 AM   #14
chrism01
Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.5, Centos 5.10
Posts: 16,269

Rep: Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028Reputation: 2028
Given that I work on various flavours of *nix, I just take the 'practical' definition ie the default is whatever you get if you DON'T explicitly define it yourself
Basically never 'assume' ...
https://secure.wikimedia.org/wikiped...Don%27t_assume

Also, others may have a hand in setting the env where your script ends up running.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Bash scripting line wrapping best practices kushalkoolwal Programming 7 07-21-2011 07:32 AM
Bash scripting -- parsing a directory path int80 Programming 10 08-11-2009 12:32 PM
functions in bash scripting wvw Programming 4 05-14-2009 05:22 PM
[bash-scripting]functions + arguments hylke Programming 14 10-05-2004 01:48 AM
Good scripting practices? test Programming 2 04-26-2004 10:55 PM


All times are GMT -5. The time now is 11:47 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration