Permission change /bin/sh for security

H

hmiddelhoek

Hello,
Users that aren't a member of the group wheel don't need access to /bin/sh, /bin/csh or /bin/tcsh in my opinion. In our situation I don't need this, it's a shared webserver where users can create cronjobs, users don't have shell access, but they can run a shell script from cron. In my opinion that's a security risk. I know they can't reboot/shutdown the system, or see the /etc/master.passwd and many other important files, but they can do, and find out, more than I want them to.

My simple thought was to # chmod 550 /bin/sh (and the other shells from /etc/shells. The owner and group are root:wheel. That way root can login normally and users with shell access, like myself, can login because I'm a member of wheel. This works fine as far as I can tell now, except for /usr/libexec/save-entropy from /etc/crontab:
Code: 
*/11    *       *       *       *       operator /usr/libexec/save-entropy

That gives the following error:
Code: 
cron: execl: couldn't exec `/bin/sh': Permission denied

It runs as the operator user, I understand why this doesn't work, but I'm looking for an elegant solution. I can simply add operator to the group wheel, but I'm not aware of security issues with that. Another solution could be to make operator owner of /bin/sh, root is already a member of wheel, but again I'm not sure if this is a good solution. Last option would be to run the save-entropy as root user, but I imagine there a legitimate reason it's running as operator by default.
 
In our situation I don't need this, it's a shared webserver where users can create cronjobs, users don't have shell access, but they can run a shell script from cron.
Click to expand...
Which requires access to a shell.
In my opinion that's a security risk.
Click to expand...
Then don't give them shell access (or access to cron).
 
SirDice said:
Which requires access to a shell.

Then don't give them shell access (or access to cron).
Click to expand...

By
but they can run a shell script from cron
Click to expand...
I meant that it's possible right now and I don't want that because of the security risk. There's not even one user with a website who has shell access, all have /usr/sbin/nologin as login shell. So, that's not the problem.

Giving them no access to cron prevent them from running php scripts from cron and that needs to be possible.
 
If they can run php scripts from cron you might as well give them access to the shells.

What exactly are you trying to prevent? And no, I didn't mean shell access, I mean what they can do with it that's causing security concerns.
 
SirDice is right. There are numerous ways your system can be compromised by an attacker. They don't need to run /bin/sh once they "hack" your www user, they can just upload their own shell and run it as if it were your own /bin/sh, or open a covert channel, etc. Once they get user access on your system it's just a matter of time to get root access (if they know what they're doing).

I would totally understand if you wanted to change permissions so as to remove suid bits from binaries you don't use, but what you are trying to do does not enhance your security in essence.

I don't wish to start a security-related non-stop conversation, so whoever feels the urge to reply to my comment, please don't. I just place a subjective opinion regarding the specific matter.
 
Thank you for your comments.

The shared webserver runs hundreds domains and sometimes a user 'loses' their password. I know there are a lot of possibilities to compromise a system, but I'm trying to tighten as much as possible without noticing effects for the website and their users. Yes, they can upload their own shell, or something else, you're right, but it get's harder everytime something is closed. In PHP we don't allow exec(), shell_exec() and system() for example. At this moment it's possible a user uploads a shell script, runs it from cron and see the contents of /etc/passwd. Not very harmful, but they can find the usernames with shell access. We took actions to prevent brute force on SSH and run it on another port than 22, but the contents of /etc/passwd and many others isn't meant for public viewing. That's what I try to accomplish.

You're probably right that what I try to do is meaningless, but don't you agree this is making it a little harder? The attack should be very targeted and done manually to find the 'holes'.

Besides your thoughts about the security enhancement, is it possible to accomplish what I want(ed), I really reconsider it because your 'thoughts' about it, but I'm still curious how I could accomplish it (best).

Thank you again.
 
Ah, now I understand. I don't have a complete solution but I think moving your users to something like LDAP could prevent it. At least it won't be as simple as reading /etc/passwd or looking at the /home/ directory structure.
 
hmiddelhoek,

all opinions stated by SirDice and gordon@ are a step towards "tighter" security. The more layers you use, the better; for my servers, I run them in jails, I use a setup that allows write access only in /var and /tmp. Each time I upgrade I run a script that removes all suid bits from my binaries (except from login, if I remember correctly), enables some restrictive acls on binaries and configuration files, enables chflags on binaries and configuration files(even though the filesystem they are stored is mount read-only), I keep my users in ldap, connection to ldap is allowed only via SASL/GSSAPI, so all passwords are stored in kerberos. Postfix, dovecot, and all other services I run use kerberos for authentication, directly or indirectly (through PAM), nsswitch relies on ldap, ssh authentication is allowed either with key or with a kerberos token, I have removed suid bits on passwd, kpasswd, etc. so users can change their password and gecos stuff only by logging into a cgi web page we have created that calls a "client" we have written in C (that resembles suexec()) using mod_auth_kerb, which connects with a socket where a server listens (written by me and the rest of my admins in C/C++) that communicates with ldap/kerberos/rest_of_databases (using their APIs) to update all user data simultaneously... and now I have a terribly difficult system to administer :D:D

This way, if/when a hacker brakes in, they will find it a bit difficult to dig their way out of this mess. On the other hand, I am sure there are a few holes in my system that I have never thought about, and that exist because of my "complicated" setup.

Good luck with your setup, and try to secure your weakest links first (as you might already have done), meaning php and/or sql, www user account, binaries, jails, etc.

PS: I haven't understood your cron-thing thoroughly, but this would be the first thing I would secure; either by adding a layer of abstraction to the end user when entering cron jobs, or by disabling it, and giving some access to my users via a restricted-shell, or another layer of abstraction (web-page/service).

PS2: Despite all my efforts, I am certain that my system will be compromised in the future, and hopefully nothing very very bad will happen (if I keep backups regularly).
 
@SirDice
Moving to LDAP is no option. I just gave /etc/passwd as an example.

@gordon@
I'm not familiar with that option. I will study it as it looks interesting. Thank you.

@mamalos
Wow. The intruder isn't the only one with problems finding it's way around I guess :-) Your setup sounds very secure, but every system has vulnerabilities, like you said. Finding them will likely be much more time-consuming in such setups.

I like to tighten the security but with administration in mind. Basic security is done for www, php and mysql, etc. As far as possible in a shared webserver setup based on an existing control panel. We use DirectAdmin, but same applies to Plesk, cPanel and others.

PS: I haven't understood your cron-thing thoroughly, but this would be the first thing I would secure; either by adding a layer of abstraction to the end user when entering cron jobs, or by disabling it, and giving some access to my users via a restricted-shell, or another layer of abstraction (web-page/service).
Click to expand...

In control panels like DirectAdmin, users can have the ability to run cron jobs. For example to process sending a newsletter, or generating XML files from the content of your website, automatically update your sitemap.xml, etc. This means cron access can't be shut, it would be nice, but customers wouldn't agree, I'm sure :-) It's very common to allow customers to create cron jobs. That's the basic cron-thing. Besides that there is no user with a login shell, not jailed or something, simple enough not allowed. Only our system administrators are allowed to login to the shell. Users can make use of the FTP server (also secured) to manage their files, or ask us in special cases to support them. This means that the accounts on our servers don't have shell access. But here's my point. User's can run shell tasks by making a shell script and call it via cron. This way denying shell access is useless. We could give everyone a login shell and they have the same possibilities as running a shell script via cron. I don't want them to have the ability to run shell tasks. Having this possibility reveals to much information and possibilities to user accounts. Especially when an user 'loses' his username and password.

Going back to my originally posted question. I want to change the permission on /bin/sh so users can't access it. A chmod 550 works fine when user root and group wheel are owners. Only problem is the following cron job:
Code: 
*/11    *       *       *       *       operator /usr/libexec/save-entropy

User operator can't access /bin/sh anymore. My questions:

1. Can I change the operator user to root, or is this unsafe (operator is chosen for a particular reason I think?). Or can I add operator to group wheel, or does the same apply on this?
2. Can I expect more problems than only this cron when I'm changing these permissions?

P.S. this is additional in our other security. We use a firewall, virus scanner on FTP file uploads and e-mail, open_basedir restrictions in PHP, denying some PHP functions like exec(), system() and shell_exec(). Special mount options on our partitions, many sysctl values are changed for security or optimization. Running SSH on another port and only allow some users, checking login attempts with bruteblock and append attackers to the firewall (bruteblock also works for FTP and Dovecot), running syslog only local (-ss), DirectAdmin doesn't run on the default port. We hide as much information as possible to make it harder to determine the versions of our OS and applications. It's all pretty basic but enough for our webservers, tightening it too much would break possibilities of the control panel. I'm always looking for improvements in security and /bin/sh looked like a very simple approach which is very easy to administer :-) I'm aware that this isn't a real security thing, but it helps a little in my opinion.

Thank you.
 
hmiddelhoek,

add an acl on /bin/sh that allows operator to use it. Then remember to add this acl each time you update your system. (I run a script that "unsecures" my system before installing world and a script that "secures" it after I install world. These scripts do such operations: passing chflags, acls, etc on specific files and folders).

As far as your second question is concerned, I am unable to answer it, because I've never given any thought about it, since I would never disable /bin/sh, despite my paranoia :)

PS. Beware of the use of such programs like DirectAdmin, cpanel, etc. I've heard of a few, very easy to abuse vulnerabilities (0days) regarding some of them at the time of this writing (no exploit/shellcode needed for abuse).
 
Mamalos,

Thank you! An ACL was what I needed to get it to work. I haven't used it before and wasn't aware of it's existence anymore, despite my reads in FreeBSD handbook years ago.

You wrote about scripts for securing and undo security before updating. I'm reviewing all our security at the moment and got very curious about your other acls. I can't think of any use for it and can't find it in security documents, or howto's. I don't ask you to share your scripts, but am interested in some other interesting uses for acl. The chflags options are great but for our use to restrictive, I don't think I'm going to use that anywhere.

But again, /bin/sh is secured for 'public' use. Only root, operator and members of group wheel are allowed to execute. I'm happy with it :-)
 
hmiddelhoek,

the content of your acls and the places they should be put depends on your setup. A common use of my acls is to have 0700 permissions for my home directories, and allow www user to execute on their directories, in order to be able to access (at least...) their public_html directories. Depending on your setup, you may put many custom acls like that to suit your needs; this way you may "harden" your system a bit, without compromising the useability/integrity of your system. Don't forget to:

# tunefs -a /dev/filesystem_with_acl_support

in order for your filesystem to actually support acls, in case you've forgotten it :).


Glad that I could be of help,

mamalos

PS. I always have my binaries in /bin/, /usr/bin/, etc and libraries "protected" by setting the schg extended attribute after I upgrade my system. This way, it is not that easy for somebody to tamper with them, even root, if my security level is > 1. This is a requirement that always holds within my jails.
 
You must log in or register to reply here.
Back
Top