Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Does anyone know of a docu, guidline or book which explains how to write secure code for bash scripts in general? Strangely I didn't found anything in google and in the forum so far.
If someone here is willing to review a bash script for me (about 600 lines) and help me to make it as secure as possible please send me a PM.
Thanks
Norbert
Click here to see the post LQ members have rated as the most helpful post in this thread.
The tips are same: don't trust user input and double-check everything: that's the way to build a secure program.
Pastebin your script, more people will review it then.
But probably, this topic more suits for "Programming" forum.
A few more ideas. Control the environmental variables. Keep/define only environmental variables you need & clear the rest. Use full paths for commands. Explicitly indicate "builtin" before builtin commands. Handle all errors that might occur. Trap signals. For programs for services, you could root jail the service.
Thanks for your hints. I will try to implement them. Here is the script as it is now. (The idea behind it is a Nagios plugin which does some simple security checks.)
Hmm, no one likes to help/review? I would pay for it.
Two things: please be patient and do not use money as incentive. It is unnecessary and (while I'm sure you didn't mean it that way) not respectful to those who don't have cash to shell out to get the attention their questions deserve. You're welcome to donate to LQ though.
Talking about the script itself, why not break out the config to /etc/nagios/? Editing conf files should definitely not be done in /usr/lib/nagios/libexec/ but where the FSSTND/LSB/FHS suggests it: /etc/ (or /usr/local/etc/). And why those checks specifically? Aren't they covered by other apps already (GNU/Tiger, Lsat, Samhain)? I'd expect file attribute changes like boot_lilogrub_imflag and file_perms to be checked by a file system integrity checker because using a made for the job tool would more versatile. Besides checks like kernel_coredumps_no, kernel_syncookieprotection_on, kernel_loaded_modules mean changes made by root so that really calls for an application with a wider scope IMHO. If Sudo was not previously installed, in what way would the user be notified of check failure? You're defining the IFS inside each function but it gets only changed in one place AFAIK, is that necessary? You're defining the IFS, which itself is good, but if you do, shouldn't you also check out setting POSIX? (Also see GNU SW and POSIXLY_CORRECT (and POSIX_ME_HARDER)). In 'function kernel_syncookieprotection_on()', if "${PAR_kernel_syncookieprotection_on}" does not exist, what value would cat return and what effect would that have on the script? In 'function file_perms()', what happens to filenames with commas in them if you 'filename=`builtin printf "%s" "$i" | cut -d"," -f1`'? Where you "# remove leading commas", couldn't you use VAL="${VAL/,/}" instead? So many questions, so little time...
Two things: please be patient and do not use money as incentive. It is unnecessary and (while I'm sure you didn't mean it that way) not respectful to those who don't have cash to shell out to get the attention their questions deserve. You're welcome to donate to LQ though.
Well, it was not meant to be disrespectful to anybody, not at all. I wanted to give something back to the one who looks through the code. I have donated to LQ instead.
Quote:
Talking about the script itself, why not break out the config to /etc/nagios/? Editing conf files should definitely not be done in /usr/lib/nagios/libexec/ but where the FSSTND/LSB/FHS suggests it: /etc/ (or /usr/local/etc/).
I did it this way because I didn't want to introduce another configuration file. Also I didn't realise that it is against LSB. I will put the configuration stuff in a separate file then.
Quote:
And why those checks specifically? Aren't they covered by other apps already (GNU/Tiger, Lsat, Samhain)? I'd expect file attribute changes like boot_lilogrub_imflag and file_perms to be checked by a file system integrity checker because using a made for the job tool would more versatile.
Yes they are covered. And for servers where a really high level of security is needed I would install those programs. But I wanted a simple way to do some security checks without additional effort (and knowledge). Think about monitoring thousands of servers and you had to install and configure on all these systems additional daemons and config files. Also you have to integrate each of this software individually into the monitoring.
Quote:
Besides checks like kernel_coredumps_no, kernel_syncookieprotection_on, kernel_loaded_modules mean changes made by root so that really calls for an application with a wider scope IMHO.
This points to the same direction. So I will do some research what and how heavy-weight security apps could be integrated into nagios. But at least those checks shouldn't do any harm.
Quote:
If Sudo was not previously installed, in what way would the user be notified of check failure?
Hmm, I tested it and Nagios just displays (null) which of course is not good. So I will add a verification in the script that sudo is installed and otherwise print a useful error message.
Quote:
You're defining the IFS inside each function but it gets only changed in one place AFAIK, is that necessary?
Another hit, I will change this too.
Quote:
You're defining the IFS, which itself is good, but if you do, shouldn't you also check out setting POSIX? (Also see GNU SW and POSIXLY_CORRECT (and POSIX_ME_HARDER)).
Didn't know of these, will fix this too. What do you mean by GNU SW?
Quote:
In 'function kernel_syncookieprotection_on()', if ${PAR_kernel_syncookieprotection_on}" does not exist, what value would cat return and what effect would that have on the script?
Interesting, the script hangs endlessly, the next thing to fix.
Quote:
In 'function file_perms()', what happens to filenames with commas in them if you 'filename=`builtin printf "%s" "$i" | cut -d"," -f1`'?
And another one, thanks.
Quote:
Where you "# remove leading commas", couldn't you use VAL="${VAL/,/}" instead?
Seems to work. I will see what can be replaced by shell builtins, there are probably more commands which can be simplified.
Quote:
So many questions, so little time...
Thank you for this valuable info. In the meantime I am going to remove these bugs. If you like please let me know other concerns too if there are more...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.