Given the dangers of SUID shell scripts, is there a more secure way of giving passwordless access to scripts (bash, PHP) with root permissions in Linux?
(Ubuntu 8.10)
You could consider sudo.
Although not 'passwordless', it doesn't require the user to be given the root password. It can also provide an audit trail of use of the script.
edit: as per comment from Chris, there is an option not to require a password at all for certain commands, see here for details. It can also be set up not to prompt excessively for the password, i.e. one entry of the password can be good for multiple commands over a period of use.
By the way, sudo is built in to Ubuntu and nicely integrated with Gnome. When ubuntu prompts you for your password to do privileged operations, that's sudo under the hood.
Be sure to review the "PREVENTING SHELL ESCAPES" section of the sudoers man page if you go the sudo route.
I would recommend sudo. Be sure to tighten your sudoers file appropriately; and yes, you can allow some commands to be executed with no password being requested.
Configuring sudo to let normal users run shell scripts with elevated privileges isn't any better from a security standpoint than making the script suid root. All the pitfalls still exist.
Instead you should write a proper program that does extensive security checks. Some points to consider:
Don't write it in C, you'll shoot yourself in both feet.
Check all inputs.
Drop privileges as soon as possible.
Keep it short.
Since sudo has already been mentioned, you might want to consider various sandboxed environments, depending on your needs — e.g., jail or similar.
For a really heavy-weight solution, consider a MAC (Mandatory Access Control) system, like SELinux, AppArmor, TrustedBSD etc.
To improve security consider whether it is possible to do the operation as a special user or group, which has exactly the access rights needed for it. Then you can make the script setuid/setgid for that user or group.
If the use case is a machine running under VirtualBox and security isn't really an issue, you just want a light barrier to prevent yourself shooting yourself in the foot, what then? (Then the security arguments don't really make sense, since it doesn't matter if the machine gets compromised by an outsider who can't see it anyway due to the way VirtualBox insulates it via NAT.)
Related
On Linux, how can I give www-data more permissions/privileges when I am logged in as that user? whoami = www-data
A bit of background. I have performed an ethical hack on a web application, I have managed to upload a file by bypassing the extension type which allows me to open a remote shell through netcap. The issue is, the default user for netcap is www-data and I cannot change user or escalate as I do not know how.
Any help would be great!
You can use sudo -u <another-user> command to gain the privileges of another user.
It may be intentional or maybe not, but you're basiclly asking "How to hack". If this is in purpose of homework, please add the homework tag to your questions.
Since you're saying it's a pentest, I'll assume this.
The first thing to do is to see what file do you have access to, and what you can do with them, and then perform the basic task of a pentest like checking the versions of the used packages, softwares or framework and to see if they're any known exploit on them.
I would like to use a callback feature of an SVN repository (Unfuddle) to ping a URL on my server whenever a commit has been made. I have a PHP script accepting the message and attempting to call a shell script to execute an 'svn update'.
The problem I'm facing is that Apache is running under user 'www-data' and does not have access to the local repository: '.svn/lock' permission denied. I have read all about setting SUID/SGID on shell scripts and how most *NIX OS's simply don't support it because of the security risks involved.
However I can set the SUID/SGID bit on the SVN binary file located at /usr/bin/svn. This alleviates the problem by allowing any user to issue SVN commands on any repository; not the most ideal...
My question is what's the most logical/sane/secure way to implement this type of setup and if I did leave the bits set on the svn binary does that open up a major security risk that I'm failing to realize?
Sorry for the long-winded post; this is my first question and I wanted to be thorough.
Thanks
There are 2 types of solutions for this kind of problem, polling or event driven.
An example of a polling solution would be to have a cronjob running on your server updating every N minutes. This would probably be the easiest to maintain if it works for you. You would sidestep the whole permissions issue by running the cron from the correct account.
The solution you covered is an event driven solution. They are typically less resource intensive, but can be harder to set up. An another example of an event driven solution would be to have www-data belong to an svn group. Set the SGID bit and chown the repository directory to the svn group. This should allow anyone in that group to check-in/out.
If you need to limit to updating, you can escalate privileges or change user temporarily. You use ssh single purpose keys (aka command keys) to ssh in as the user with the correct privileges. The single purpose key can then be used to do the update.
Another way to escalate privileges would be to use sudo -u [user] [command]. Update the /etc/sudoers file to allow www-data to escalate/change user to one that can perform the update.
Either way I would NOT use SUID/SGID scripts.
As CodeRich already said, you can set up a cron job to frequently update tue working copy(that's also the solution I would use).
Setting svn SUID/SGID is bad, because svn can write files everywhere in the file system (think of a public accessible repository containing a passwd and shadow file, checked out into your /etc). You could use a little suid wrapper program(which is SUID to your user account, not root), which chdir into your working copy and executes svn with the correct parameters there. You can look at ikiwiki which does this when it is used as a cgi.
Another way is to change the permissions of your working copy, so that the www-data user can create and write files there.
change the permissions on your working copy so that Apache can write to it. You have a directory you want to change, you need permissions to do so. Its that simple :)
The problem you then face is allowing any Apache user (or hacked page) to write all over your repo, not a good thing. So - you need to only allow a part of the system to write to it, and the best way to do that is to run your php script as the user who already owns the repo.
That's easily achieved by running the php script as a cgi, or fastcgi process. You can specify the user to use, it doesn't have to be www-data at all, though it does require a bit more setting up, you can have the best of event-driven and security as you're likely to get.
Here's a quick explanation of phpSuexec that does this.
I want to build a web based admin tools that allow the system admin to run pre-configured commands and scripts through a web page (simple and limited webmin), what is the best approach?
I already started with Ubuntu installing LAMP and give the user www-data root's privileges !!!
as I learned (please check the link) this is a really bad move !!!, so how to build such web-based system without the security risk?
cheers
I did something like this a couple of years ago. It was (I like think) fairly secure and only accessible to a limited number of pre-vetted, authenticated users, but it still left me with an uneasy feeling! If you can avoid doing it, I'd recommend you do :)
I had a database sitting between the frontend web-tier and the script which was actually executing actions. The relevant table contained a symbolic command name and an optional numeric argument, which was sufficient for my needs. This allows you to audit what's been executed, provides a quick and dirty way to have a non-www user do things, and means if the website is compromised they're constrained by the DB structure (somewhat) and the script which pulls data from it.
The data from the DB can be read by a daemon running in a separate, unprivileged account. The daemon pulls and sanitises data from the DB and maps the 'command' to an actual executable (with a hard-coded map, so commandA executes A, commandB executes foo, and anything else would get flagged as an error). The account can be locked down using AppArmor (or SELinux, I imagine) to prevent it from executing, reading or writing anything you don't expect it to. Have a system in place to alert you of any errors from either the daemon or AppArmor/SELinux.
The executables which the daemon runs can be setuid'd if appropriate, or you can use the sudoers mechanism to allow the unprivileged account to execute them without a password.
I already started with Ubuntu installing LAMP and give the user www-data root's privileges
Don't do this.
If you really want to execute some very specific scripts under root privileged. Create such predefined very limited scripts, allow their password-less execution with sudo for specific user and then run them via script and don't forget authentication.
Generally this is bad idea.
SSH is your best friend.
I want to write a server that receives and executes code on behalf of non-trusted parties.
In order to make this more secure I want the code to be run as a user that is created exclusively for running this code and then deleted.
How can I grant a non-root user the permission to create, impersonate and remove other users?
The only way you could conceivably do this is with a proxy program that's setuid root (i.e., chown root my-proxy-process; chmod 47nn my-proxy-process. And that setuid proxy program takes care of handling security considerations, setuid'ing to the named user, etc.
However the security problems with this should be fairly clear. One way it could be limited is to ensure your non-priveliged process runs with a user in a name group. Then chown thet proxy command with root:myprivategroup and chown it as 4710 so only users that are members of myprivategroup can execute it.
This is probably as secure as it can be. The main thing is making sure the proxy process is good and secure and locked down so only pertinent users can run it through group membership.
If there's any other restrictions you know can be applied to user-supplied processes, then the proxy program could validate that the process confers to those rules. Note that whilst this may be a stop gap, it wouldn't be beyond the realms of technology for someone to craft a "bad" program that passes the tests.
For added security (recommended), use a sandbox or chroot jail as mentioned by mark4o.
Maybe you can grant permissions to non-root user with sudo and /etc/sudoers, but this way seems not secure and not linear.
I don't know what you need, but maybe you can pre-create some users and then use they.
You will want to use some kind of sandboxing or virtualization; at least a chroot environment at minimum. See also Sandboxing in Linux.
This is a problem as you can not use su vie script without the terminal (probably a security feature). I'm sure you can hack your way through this, but it was probably done for a good reason.
Conducting a user account cleanup accross Solaris and Redhat linux systems, many of which have a number of Samba shares.
What preference do people have for creating the local unix accounts for non interactive Samba users? In particular, the shell entry:
noshell
nologin
blank
And why?
JB
I have seen the shell set to the passwd command so that logging in only gives an opportunity to change the password. This may or may not be appropriate in your non-interactive user case, but it has the upside of allowing people to change passwords without bothering an admin.
I've always thought /bin/false was the standard. Some ISPs use a little menu system that lets them change their password / contact / finger info, check usages, etc. Whatever you use, you may want to add it to your /etc/shells file as well if you want the user to be able to use FTP for instance, as some services will be denied to users who are not using a shell listed in that file.
I usualy send all mine to /dev/null that way I don't ever have to worry about it.
I have known some people who set it to /bin/logout so that when someone logged in they were logged back out.
Don't do blank. That runs /bin/sh.