I am making a Linux application using Python3 and Qt5. When user will install this application, It will create some files in /usr/share folder. To create the files the application needs to have root access.
I plan on having the application show a prompt box to user and user will enter the root password to give root access to the application. But I don't know that how can I give root access to the application by using that password?
This is a world of pain. It's certainly possible to have an application that runs as a normal user carry out certain actions as a privileged user, but I always feel that the need to do this suggests that installation and maintenance hasn't been thought through properly.
To elevate privileges, and assuming the "sudo" isn't appropriate (it probably won't be in this case), you will either need to use an operating system tool that does the job (prompting for credentials and then running something), or implement a helper for your program that has suid attributes on its executable.
I expect all Linux systems have access to "su", but the standard su doesn't have a graphical interface, which is a drag for GUI programs. You can collect the user credentials in your application, and then pass them to su (which is fiddly), or you can use one of the various graphical su-type utilities such as gksu. Of course, that only works if those utilities are available on your platform.
If you go the route of providing your program with a suid part that handles the work that needs elevated privileges, you need to be inordinately careful about security -- how you collect the credentials, how you verify that intruders can't do things they shouldn't, etc.
Frankly, it's a can of worms. I would think that it's nearly always better to provide your application with an installation or maintenance module that has to be run as root. That way all the hard work gets done by the platform.
Related
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.
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 have a UI app (uses GTK) for Linux that requires to be run as root (it reads and writes /dev/sd*).
Instead of requiring the user to open a root shell or use "sudo" manually every time when he launches my app, I wonder if the app can use some OS-provided API to get root permissions. (Note: gtk app's can't use "setuid" mode, so that's not an option here.)
The advantage here would be an easier workflow: The user could, from his default user account, double click my app from the desktop instead of having to open a root terminal and launch it from there.
I ask this because OS X offers exactly this: An app can ask the OS to launch an executable with root permissions - the OS (and not the app) then asks the user to input his credentials, verifies them and then launches the target as desired.
I wonder if there's something similar for Linux (Ubuntu, e.g.)
Clarification:
So, after the hint at PolicyKit I wonder if I can use that to get r/w access to the "/dev/sd..." block devices. I find the documention quite hard to understand, so I thought I'd first ask whether this is possible at all before I spend hours on trying to understand it in vain.
Update:
The app is a remote operated disk repair tool for the unsavvy Linux user, and those Linux noobs won't have much understanding of using sudo or even changing their user's group memberships, especially if their disk just started acting up and they're freaking out. That's why I seek a solution that avoids technicalities like this.
The old way, simple but now being phased out, is GKSu. Here is the discussion on GKSu's future.
The new way is to use PolicyKit. I'm not quite sure how this works but I think you need to launch your app using the pkexec command.
UPDATE:
Looking at the example code on http://hal.freedesktop.org/docs/polkit/polkit-apps.html, it seems that you can use PolicyKit to obtain authorization for certain actions which are described by .policy files in /usr/share/polkit-1/actions. The action for executing a program as another user is org.freedesktop.policykit.exec. I can't seem to find an action for directly accessing block devices, but I have to admit, the PolicyKit documentation breaks my brain too.
So, perhaps the simplest course of action for you is to separate your disk-mangling code that requires privileges into a command-line utility, and run that from your GUI application using g_spawn_[a]sync() with pkexec. That way you wouldn't have to bother with requesting actions and that sort of thing. It's probably bad practice anyway to run your whole GUI application as root.
Another suggestion is to ask the author of PolicyKit (David Zeuthen) directly. Or try posting your question to the gtk-app-devel list.
We have an embedded linux product with an application which lets the user change different settings through the menu system. These settings include IP address/DHCP and time.
We now run this application as root but this feels wrong, letting the user directly interact with a process run as root.
Which user should we use?
If not root, how do we accomplish the permission issues that arise?
EDIT:
The product does not have a graphical user environment in the classical Gnome/KDE fashion. The menu system mentioned is implemented on an LCD panel on the product itself.
If strict controls are applied to input, there is nothing wrong to run an embedded application as root on Linux.
Anyway, when the underlying OS is something like VxWorks, applications run with maximum privileges as well.
I think the question is: what would happen if something goes wrong? I assume the product would just crash and hang or misbehave in any case? The concept of root vs regular user really only applies if there is something that not being root can protect against... which if all you have is a fixed UI does not seem to be the case.
If the application is the main part of the system, then it makes sense to run it as root.
However, even if there is some extra work, it is worthwhile to uncouple your application with your GUI, so your GUI can run with as a normal user.
This can also help you automate your tests.
This assumes that you're running GNOME.
1) Do what the program "Users and Groups" does. It allows you to see the current settings but requires you to unlock the advanced settings such as managing other users.
2) Use gksu extensively.
I would split the code into parts. Create a user for your interface code. You could name it "interface." Then have it call into root via a daemon or sudo to actually execute the changes that require root. Limit the access so that only approved commands can be run.
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.