I am writing a program, and want it to run with reduced privileges. I know as root I can do this, but what about as a normal user. Can I set the user to nobody, without first setting it to root?
No, you cannot change the user of a process to nobody without root permission.
The relevant syscalls are setuid(2), seteuid(2), setresuid(2) ...
(There might be perhaps a Linux-specific way of restricting new file operations on a process, but I can't recall the details)
See also SE-Linux, Setuid, credentials(7), capabilities(7) and read Advanced Linux Programming ...
You do not need to set root permission, but you must start the program as either a root user or another admin user.
Related
I understand that setUID bit works with the EUID and RUID in Linux to give non-provisioned users temporary root access to executables that require it. However, my main concern is that let's say a process is malicious on a computer. Even if the process has a low-privileged User-ID (like "nobody" on Macs), if all they can do to execute code is work with files that have the setUID bit to get a temporary root EUID, wouldn't that defeat the whole purpose of having privileged processes, as that process now technically has root access to the computer? Or am I missing something? Thanks!
Just because an executable has privileged access doesn't mean the person who executes it can cause it to do arbitrary actions.
Programs that are intended to be run under setuid must be written very carefully to avoid being used in unintended privilege-escalating ways. If they have security flaws, yes, it will create exactly the problem you describe, and you must be very careful before applying the setuid flag to executables.
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 read from some books that the seteuid together with euid and saved UID can be used to drop root privilege temporarily. The case is:
set euid to a non-root one.
do something which does not require root privilege.
set euid to root again (this works because root is still the saved UID).
I think this is flawed. During step 2, some malicious code could also invoke seteuid to root so this method of dropping root privilege doesn't prevent hijacking code from gain root privilege. Is my analysis correct? If so, what could seteuid-on-saved-UID be used for?
Your concern that the malicious code might also restore the effective UID to the saved UID is legitimate. If you are concerned about this, maybe you should not be using a setuid root program in the first place. (LD_PRELOAD and other such things are worrisome in general; they are also restricted when a program is running with setuid privileges.)
Often, though, the mechanism is used in a forked child, where the child will execute some other process without the elevated privileges because the saved UID won't be retained by the executed process. If the malicious code manages to take over before the exec(), then you still have problems. After the exec(), the malicious code only has the privileges of the real UID, and the user could have done whatever it is that the malicious code did.
Setuid is flawed in general, because of the possibility of privilege escalation without authentication. Even the notion of root privilege is getting a bit antiquated. Most platforms have updated methods for gaining additional privileges, whether it be from shell with "sudo" on unix and "pfexec" on Solaris, for example.
Additionally they generally have more fine grained controls on which privileges they need escalated. With setuid, its all or none, but with RBAC on Solaris for example, the framework provides methods for specifying which exact privilege(s) you need, generally lower level stuff like opening files, reading directories, etc..
In general, I think now days you should avoid setuid for anything and use newer APIs instead.
I'm really new to Linux. I Google'd for couple of days, and installed Java and Tomcat in CentOS.
Now I need a user, that has all privileges in their home directory (including files, subdirs and files in subdirs), but cannot access any other dir.
Also this user has to have a permission to manage one service (I created tomcat service, which I can 'start','stop' and 'restart').
Can anyone explain how to do this?
You've asked for a lot.
There's a few approaches possible:
Entirely with "native" Linux permissions
Using a mandatory access control system
Native Linux permissions
Create this new user their own new group. Make them the only member of this group.
Remove world read, write, execute permissions on all your data files. If any users were getting their privileges to the data files via world permissions, either create new groups for all the users and data as appropriate (maybe one for accounting, one for billing, one for sales, one for engineering, etc. Whatever works.)
Add a new sudoers(5) entry for this user for the sudo stop tomcat, sudo start tomcat, sudo restart tomcat, sudo status tomcat -- or whichever commands this user will need to execute to manage the tomcat service. See visudo(8) for details on editing the sudo(8) config file.
If you really want to lock this user down, copy in the utilities that this person will need into their ~/bin/ dir and then proceed to remove the world execute bit on /bin, /sbin, /usr/bin, /usr/sbin. (Leave /lib, /usr/lib, etc. alone -- copying in the libraries this user will need is doubtless a lot of work.)
Mandatory access controls
I'll explain this using the AppArmor system; I've worked on AppArmor for over a decade, and it is the system I know best. There are more choices: TOMOYO, SMACK, and SELinux are all excellent tools. AppArmor and TOMOYO work on the idea that you confine access to pathnames. SMACK and SELinux work on the idea that every object on the system is assigned a label and the policy specifies which labels (on processes) can read, write, execute, etc. labels (on data or other processes). If you wanted to enforce a comprehensive Open, Classified, Secret, Top Secret style of protection, SMACK or SELinux would be the better tools. If you want to confine some programs to some files, AppArmor or TOMOYO would be the better tools.
AppArmor should come ready-to-use on most Ubuntu, SUSE, PLD, Annvix, Mandriva, and Pardus distributions.
The AppArmor system confines processes and controls how processes can move from domain to domain when the processes execute new programs. Domains are usually assigned by program.
The easiest way to get started is to copy /bin/bash to /bin/jail_bash (or some other name not in /etc/shells), set the shell for the user in /etc/passwd (chsh(1) can make this easy), and create an AppArmor profile for /bin/jail_bash that allows only the actions you want to allow. If we confine the process correctly, then the user cannot escape the profile we make for them.
Add a new sudoers(5) entry for this user for the sudo stop tomcat, sudo start tomcat, sudo restart tomcat, sudo status tomcat -- or whichever commands this user will need to execute to manage the tomcat service. See visudo(8) for details on editing the sudo(8) config file.
In one terminal, run aa-genprof jail_bash. In another terminal, log in as the user (or otherwise run /bin/jail_bash) and begin doing tasks that you want to allow the person to do. We'll use what you do as training material to build a profile iteratively. You might be interested to watch /var/log/syslog or /var/log/audit/audit.log (if you have the auditd package installed) to see what operations AppArmor notices your program doing. Don't do too much at once -- just a few new things per iteration.
In the aa-genprof terminal, answer the questions as they come up. Allow what needs to be allowed. Deny what ought to be denied. When you are asked about execution privileges, prefer inherit or child over profile. (The profile option will influence every one else on the system. Inherit or child will only influence executions from whatever profile you're currently working on improving. Child breaks apart privileges into smaller pieces, while inherit keeps permissions in larger profiles. Prefer inherit for this case.)
Once you get to questions about executing tomcat, use the unconfined execute privilege. This is dangerous -- if a bug in the way tomcat is started allows people to start unconfined shells, then this can be used to break out of the jail. You could confine tomcat (and this is even a good idea -- tomcat isn't perfect) to prevent this from being an escape route, but that is probably not necessary right away.
AppArmor is designed to make it easy to grow the profiles on a system over time. AppArmor isn't applicable to all security situations, but we deployed scenarios very similar to this at the DEF CON Capture-the-flag hacking contest with excellent results. We had to allow fellow attackers root (and ephemeral user accounts) access to the machine via telnet, as well as POP3, SMTP, HTTP+CGI, and FTP.
Be sure to hand-inspect the profiles in /etc/apparmor.d/ before allowing your user to log in. You can fix anything you want with a plain text editor; run /etc/init.d/apparmor restart to reload all profiles (and unload the profiles you might remove).
It's handy to keep an unconfined root sash(1) shell open when you're first learning how to configure AppArmor. If you ignore the warning about programs that shouldn't have their own profile, it might be difficult to get back into your own system. (Don't forget about booting with init=/bin/sh in the worst of situations.)
You can easily create a very restricted environment by starting bash in restricted mode. Set the user's shell to rbash instead of bash, and that will put it into restricted mode.
http://www.gnu.org/s/bash/manual/html_node/The-Restricted-Shell.html
There's a chance that rbash will be too restrictive for your needs. Among other things, the restricted environment forbids changing directories. But take a look at it and see if it's sufficient for your needs.
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.)