{"id":36,"date":"2010-05-12T20:30:38","date_gmt":"2010-05-13T00:30:38","guid":{"rendered":"https:\/\/ebs-dba.com\/wp\/?p=36"},"modified":"2017-09-06T08:04:24","modified_gmt":"2017-09-06T12:04:24","slug":"unix-script-security","status":"publish","type":"post","link":"https:\/\/ebs-dba.com\/wp\/blog\/2010\/05\/12\/unix-script-security\/","title":{"rendered":"Unix Script Security"},"content":{"rendered":"<p>I have received a lot of questions about this area recently. Here are a couple of tips and tricks I use to provide security within shell scripts.<\/p>\n<p>Note: The syntax I will use is for Bourne type shells. The same concepts apply to csh, but the syntax changes.<\/p>\n<p>The first scripting security issue for DBAs that we need to address is the problem of passwords in scripts. Many scripts we write as DBAs, especially applications DBAs, need to connect to the Oracle database. Unfortunately, these scripts frequently contain hardcoded passwords. This has two major problems, security and maintenance. Fortunately, the solution can be simple. In a secure location, have the system administrators create a file belonging to root in the dba (or oinstall) group with permissions 660 (owner read\/write, group read\/write, everyone else no access). For example, \/etc\/sysconfig\/<em>SID<\/em> is a good choice in Linux. In this file, put your passwords.<\/p>\n<p>\/etc\/sysconfig\/<em>SID:<\/em><\/p>\n<pre>SYSTEM=manager\r\nAPPS=apps<\/pre>\n<p>Your scripts can source this file as part of the configuration at the start of the script. Then anywhere in the script that you need to use the password, you use the variable. In other words instead of<strong> sqlplus apps\/apps<\/strong>, you use <strong>sqlplus apps\/$APPS<\/strong>. Of course, that would still show the password with a <strong>ps<\/strong> command. An even better solution is to use i\/o redirection inside the script:<\/p>\n<pre>#!\/bin\/bash\r\n. \/u01\/app\/oracle\/db\/tech_st\/10.2.0\/VIS_vis12.env\r\nif [ -f \/etc\/sysconfig\/$ORACLE_SID ]; then\r\n  . \/etc\/sysconfig\/$ORACLE_SID\r\nelse\r\n  APPS=apps\r\nfi\r\nsqlplus \/nologin &lt;&lt;EOF\r\nconnect apps\/$APPS\r\nselect * from dual;\r\nEOF<\/pre>\n<p>After making this change, \u00a0no one who sees the script will learn the apps password, \u00a0no one who happens to issue a ps command while the script is running will learn the password, and the act of changing the password in \/etc\/sysconfig\/<em>SID <\/em>will update all of your scripts.<\/p>\n<p>Now that we have solved the major security issue within our own scripts, let&#8217;s address scripts that need to be run as root. In a segregated environment, that is one where the DBAs do not have root, sudo can be a useful tool to allow this functionality.<\/p>\n<p>For example to allow the oracle user to run root.sh from $ORACLE_HOME, you could make the following entry in \/etc\/sudoers (use <strong>visudo<\/strong> to edit this file):<\/p>\n<pre>oracle ALL = NOPASSWD: \/u01\/app\/oracle\/db\/tech_st\/10.2.0\/root.sh<\/pre>\n<p>Of course, this is is now a major security violation. \u00a0Since this script is in a directory owned by oracle, anyone who can connect to the system as oracle, can run any command they want as root simply by editing <strong>root.sh<\/strong>. \u00a0Obviously, the DBA team will continue to have to call the system administrators to have <strong>root.sh<\/strong> run when needed. \u00a0However, there are other commands that it may be more convenient to have the dba team able to run. \u00a0Examples of this may include viewing the system log, mounting and unmounting a backup or stage disk, or if cloning is done using some form of snapshot or mirroring on a SAN or NAS device, merging and splitting the mirrors. \u00a0One way to allow this is to have the system administration team write scripts to accomplish these functions and place them in a directory owned by root. \u00a0You can take the security a step further and make the directory only accessible to root.<\/p>\n<p>For example (as <strong>root<\/strong>):<\/p>\n<pre>mkdir \/usr\/local\/superuser_scripts\r\nchown 700 \/usr\/local\/superuser_scripts<\/pre>\n<p>Only root can access this directory. \u00a0If we want to allow the DBA team access to view the last 100 entries in <strong>\/var\/log\/messages, <\/strong>we create a script <strong>tail100msg <\/strong>in \/usr\/local\/superuser_scripts:<\/p>\n<pre>#!\/bin\/bash\r\ntail -100 \/var\/log\/messages<\/pre>\n<p>In <strong>\/etc\/sudoers<\/strong>, the following line is added.<\/p>\n<pre>oracle ALL = NOPASSWD: \/usr\/local\/superuser_scripts\/tail100msg<\/pre>\n<p>If the oracle user, gives the command: <strong>sudo \/usr\/local\/superuser_scripts\/tail100msg<\/strong>, they will see the last 100 lines of \/var\/log\/messages. \u00a0However, they have to know the script exists, because oracle cannot do an<strong> ls<\/strong> in <strong>\/usr\/local\/superuser_scripts<\/strong> to see what is there.<\/p>\n<p>You have to be extremely careful if you allow parameters to any scripts written for this purpose. \u00a0You have to follow all the same protections against attacks through substitution variables that are followed in sql scripts.<\/p>\n<p>Do you have any other techniques you use to improve the security of the scripts you use?<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I have received a lot of questions about this area recently. Here are a couple of tips and tricks I use to provide security within<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_monsterinsights_skip_tracking":false,"_monsterinsights_sitenote_active":false,"_monsterinsights_sitenote_note":"","_monsterinsights_sitenote_category":0,"_uf_show_specific_survey":0,"_uf_disable_surveys":false,"footnotes":""},"categories":[2,3,6],"tags":[14,12],"class_list":["post-36","post","type-post","status-publish","format-standard","hentry","category-database","category-e-business-suite","category-linux","tag-linux","tag-sysadmin"],"_links":{"self":[{"href":"https:\/\/ebs-dba.com\/wp\/wp-json\/wp\/v2\/posts\/36","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ebs-dba.com\/wp\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ebs-dba.com\/wp\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ebs-dba.com\/wp\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/ebs-dba.com\/wp\/wp-json\/wp\/v2\/comments?post=36"}],"version-history":[{"count":1,"href":"https:\/\/ebs-dba.com\/wp\/wp-json\/wp\/v2\/posts\/36\/revisions"}],"predecessor-version":[{"id":37,"href":"https:\/\/ebs-dba.com\/wp\/wp-json\/wp\/v2\/posts\/36\/revisions\/37"}],"wp:attachment":[{"href":"https:\/\/ebs-dba.com\/wp\/wp-json\/wp\/v2\/media?parent=36"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ebs-dba.com\/wp\/wp-json\/wp\/v2\/categories?post=36"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ebs-dba.com\/wp\/wp-json\/wp\/v2\/tags?post=36"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}