Posted by Nessa | Posted in linux,security,shell,tutorials,uncategorized | Posted on May 22, 2007
We started cracking down a bit on system binaries being executeable by end users on our shared hosting servers, which consisted of chmod-ing things like ‘wget’ to 700 so only root users have access. If you’re on shared host, it’s likely that you’ve encountered this kind of restriction before, and if you’re a server admin you probably know why this is necessary.
A typical scenario I’ve seen in many cases is some user’s crappity software gets exploited and executes the ‘wget’ command to download hacks and warez onto the server. I’ve also seen typical Linux functions be abused by hack processes because the access was not being controlled — it’s only safe to say that certain system binaries should be restricted to only trusted users….programs that I find particularly pervious to hacks are those like wget, lynx, scp, sh, and exec.
The issue with this (and the point of this article) is that if you suddenly disable these functions you’ll probably find yourself with a dozen complaints from your users who were using them. I’m all about fairness, so I’m not about to tell someone to rewrite their scripts because of a server-side change. Instead, I created a group on the server and added those users to be able to have access to what they needed, and chgroup-ed the binaries to that group.
I’ll use the wget example first. Say you have ‘user1‘ and ‘user2‘ that both need to be able to use wget, which is currently set to root:root 700. You’ll need to first create a file called ‘addtogroup.sh’ and insert this script:
if [ $# -ge 2 ]; then
if [ $UID == 0 ]; then
egrep ^$1 /etc/group > /dev/null
if [ $? == 0 ]; then
while [ $# -gt 0 ]; do
echo $GROUPNAME `groups $CURRENT` |sed 's/.*: //g' | sed 's/ /,/g' | usermod -G `cat -`,$GROUPNAME $CUR$
echo "the group $1 does not exist."
echo "you must be ROOT to run this script."
echo "usage: $0 grp usr1 [usr2 ... usrN]"
I know, I know, you’re probably asking why I dont use useradd +G or something like that. I tried, but in this case those commands are not appropriate. Anyways, go ahead and create your group:
root@vps [~]# groupadd wgetters
Now, simply run the script and add your users to that group:
root@vps[~]# sh addtogroup.sh wgetters user1 user2
id user1 to make sure that user was added to the group — you should see something like this:
uid=32010(user1) gid=32012(user1) groups=32012(user1),32014(wgetters)
Now if you chown the wget binary to root:wgetters / 750 , then only the users in that group can use wget, and their actual group identity would be unaffected.
It wouldn’t hurt mentioning that wget is often unnecessary, as many scripts can be run other ways:
php -q scriptname.php
lynx http://website.com/somefile.php (assuming that you have lynx enabled)