Latest LQ Deal: Complete CCNA, CCNP & Red Hat Certification Training Bundle
Go Back > Forums > Linux Forums > Linux - Security
User Name
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.


  Search this Thread
Old 01-17-2007, 03:51 PM   #1
LQ Newbie
Registered: Apr 2005
Posts: 8

Rep: Reputation: 0
Where do you generally put custom shell scripts (security-wise)?

That's it. I've tried various locations in the past, including /usr/local/bin, /usr/local/sbin, usr/local/bin/myscripts, /home/myaccount/bin... I just can't find any place completely satisfying. The point is: I do not want to put custom shell scripts in /home partition because much of these are systemwide admin scripts, and also because I mount my /home filesystem with noexec option following the security considerations. I do find it logical to put those in /usr/local/bin (and some of them in /usr/local/sbin), however I hesitate doing so as it conflicts with the point of mounting /usr partition readonly, and as many programs place their binaries in /usr/local/bin by default, making too much clutter. I assume I could deal with the latter by using a dedicated subdir like /usr/local/bin/scripts or the like (or specifying --prefix=/usr compile-time option to the programs' .configure scripts, albeit doing so possibly conflicts with the FHS), however ad-hoc remounting /usr readwrite whenever I intend to write, test and debug a script (and remounting readonly again when the job is done) simply isn't too feasible a solution, and not much secure either (in my opinion that is). Is there any known commonly agreed-upon practice for the placement of custom shell scripts, that is as much secure and as much distribution-agnostic as possible? I'd like to hear your opinions.

Thanks for your time,
Old 01-17-2007, 04:23 PM   #2
Senior Member
Registered: Jan 2004
Location: Roughly 29.467N / 81.206W
Distribution: OpenBSD, Ubuntu, FreeBSD
Posts: 1,449

Rep: Reputation: 48
Please note that noexec is not "intended" to be used for security purposes. It does provide a measure of security but does nothing to prevent shell scripts from being run. You can't run them directly but you can just type "sh scriptname" or through another method. There is nothing in place to stop that. What noexec does do is prevent "binaries" from being run and that is a wise thing for the most part.

Traditionally, /usr/local was for local scripts... so /usr/local/bin and /usr/local/sbin would be the right place for them. I recognize your frustration about it being mounted read-only (of course, they don't expect you to be changing these things daily once you move them there... only during testing). You could always mount /usr/local as it's own partition and allow it to be read-write but that's not really a good solution.

As for it being insecure to make /usr +rw for a bit then switch back to -ro ... it's not really that bad. Obviously you want to minimize the time it's writable but the only security implication involved is that no program should "write" to /usr without being told to. The odds are that if a script or local user has the rights to write into /usr, you probably already have a problem. I personally keep it read-only because it does prevent the problem. But even I remount it read-write when doing upgrades or patching programs... it keeps the window of opportunity as small as possible.

The distribution agnostic place would be in /usr/local/{,s}bin and the best idea is to write, test, and debug a script outside that directory and then move it into there. You wouldn't want someone running the script before you were done testing it... so you wouldn't want it in a place where it's in the path of all the users.

I'd use ~/bin for testing and development. And when you're pretty sure it's right... move it to /usr/local. And you can keep /home mounted with noexec (although I honestly have far too many personal scripts and programs to survive with that restriction myself) and just call them with "{interpreter} scriptname" until you're done debugging it.

Edit: Also note... shell scripts are not setuid... so they run with the rights of the user calling them. And no matter where you put them, if users can find them, and they have the rights to execute them, you have to assume they will.

Last edited by frob23; 01-17-2007 at 04:25 PM.
Old 01-17-2007, 05:31 PM   #3
Senior Member
Registered: Oct 2003
Location: UK
Distribution: Kubuntu 12.10 (using awesome wm though)
Posts: 3,530

Rep: Reputation: 63
I'd use /usr/local/... or /opt/...
Old 01-18-2007, 01:23 AM   #4
LQ Newbie
Registered: Apr 2005
Posts: 8

Original Poster
Rep: Reputation: 0
Thanks for your feedback guys. And special thanks to frob23 - your elaborate explanation gave me much insight into what I hadn't gotten quite correctly before, and reminded me of some things I used to know.



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
what are the security risks using 'passwd' in shell scripts? MisterESauce Linux - Security 5 04-10-2005 01:48 PM
Where to put mldonkey scripts? Aioth Slackware 2 06-19-2004 08:29 AM
put my scripts to PATH Boby Linux - Newbie 1 06-14-2004 12:01 PM
Put custom dropdown in KDE panel graffitici Linux - Software 0 01-24-2004 05:31 AM
bandwidth allocation by user wise and ip wise basbosco Linux - Networking 1 11-12-2003 02:54 AM > Forums > Linux Forums > Linux - Security

All times are GMT -5. The time now is 05:14 PM.

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