 |
| Tux the Linux Mascot |
The Admin Corner: Leave Environment Alone
Part of an admin's job is securing his systems. Not fun I know. But if you want to make sure that you system isn't frequented by citizens of the Peoples Democratic Region of wherever you need to take some things into account. One of those as I am learning is access to the terminal. Specifically the mesg command.
The mesg command controls the ability of other users to write to the terminal your currently logged into. The old “write” and “talk” commands allow you to send messages to other users logged into the system when “mesg y” is invoked. While this is not a huge security backdoor, it does allow for someone to circumvent security and view sensitive data on said system. So it is advised when locking down systems to use the “mesg n” command in all initialization scripts to turn off the ability for other users to write to your terminal. One problem though. /etc/environment.
The file /etc/environment is a global initialization file. You can add system wide variables in it for use for all users and daemons. So it would seem like a perfect place to put “mesg n” right? WRONG!!! I haven’t tired this on Debian distros yet but commands that deal with the terminal when put into the /etc/environment file cause … issues. I saw PAM permissions issues, authentication issues, and biggest of all all my cron jobs just stopped working. Big issue when I have reports that have to be produced daily and weekly. Luckily after some research I found the issue and took the “mesg n” command out.
Again I don’t know if this is the same for all Linux distros. But at least with RHEL (Redhat Enterprise Linux) based once be aware. You can catch most this issues in the /var/log/cron and /var/log/security files. Especially when cron jobs are supposed to launch so do a “crontab -l” or “crontab -l -u username” for a point of reference when things are supposed to happen. If you see issues specific to crond or PAM authentication try commenting out commands like “echo” or “mesg” and anything else that writes to the terminal.
Part of an admin's job is securing his systems. Not fun I know. But if you want to make sure that you system isn't frequented by citizens of the Peoples Democratic Region of wherever you need to take some things into account. One of those as I am learning is access to the terminal. Specifically the mesg command.
The mesg command controls the ability of other users to write to the terminal your currently logged into. The old “write” and “talk” commands allow you to send messages to other users logged into the system when “mesg y” is invoked. While this is not a huge security backdoor, it does allow for someone to circumvent security and view sensitive data on said system. So it is advised when locking down systems to use the “mesg n” command in all initialization scripts to turn off the ability for other users to write to your terminal. One problem though. /etc/environment.
The file /etc/environment is a global initialization file. You can add system wide variables in it for use for all users and daemons. So it would seem like a perfect place to put “mesg n” right? WRONG!!! I haven’t tired this on Debian distros yet but commands that deal with the terminal when put into the /etc/environment file cause … issues. I saw PAM permissions issues, authentication issues, and biggest of all all my cron jobs just stopped working. Big issue when I have reports that have to be produced daily and weekly. Luckily after some research I found the issue and took the “mesg n” command out.
Again I don’t know if this is the same for all Linux distros. But at least with RHEL (Redhat Enterprise Linux) based once be aware. You can catch most this issues in the /var/log/cron and /var/log/security files. Especially when cron jobs are supposed to launch so do a “crontab -l” or “crontab -l -u username” for a point of reference when things are supposed to happen. If you see issues specific to crond or PAM authentication try commenting out commands like “echo” or “mesg” and anything else that writes to the terminal.
0 comments:
Post a Comment