So I'm trying to create a way for users in Linux to create groups, then add other users to them. As far as I can tell, only root can modify groups. The reason is, I want users to be able to create a group, then chgrp/chown the files they own and give read access to specified groups of users.
My idea was to make a utility that encapsulates a "sudo groupadd " call. This utility would have access to some root-accessible file that keeps track of group ownership. Is it possible to do this without needing the user to enter root password?
I know that this is probably very exploitable, but please note that this is not going into production of any sort.
Please let me know how I can accomplish my approach (namely letting non-sudo run sudo program) or if you have any alternative suggestions.
Related
I am trying to learn some stuffs about permissions in Linux, but I am not sure I get the use of the first permission which is associated to current user.
I watched some tutorials but I didn't find my answer.
I suppose permissions in Linux are used when multiple persons with different roles are accessing a server, to give the proper permission to each of them.
So you have the command:
chmod 755 <filename>
"7" - You are setting your own permission here? what use have this? you can edit this permission anytime I suppose... . I guess "user" it is referring to directory/file owner.
"5" (1st) - I guess here you are set permission for the rest of the group and it is useful when you have more users in the same group.
"5" (2nd) - I think this is a little to much generic. For example you are hosting 2 web app on the same machine or 2 different systems on the same machine and there are dedicated teams which are administrating these. Wouldn't be proper to set permission for individual group on each location?
Sorry if my question is misleading.
Let me try to explain to the best of my little knowledge:
On linux, a user(or group) is primarily(if not entirely) defined by its permissions to do stuff (access files, execute commands) on the machine.
Everything a user "does" on the machine is actually done by a process(es) executing on user's behalf.
A process may not always do what it is supposed to do, either intentionally or due to a bug. This is where your user's permissions come into play.
For example, If you give yourself all the permissions. Then a process executing with your permissions may in worst case could do anything from stealing your passwords to accidently(or maliciously) wiping off your hard drive.
On a side note, this is precisely why running in root is considered a security risk and is the whole point behind creating an unprivileged user.
Hope I answered your question.
I need to allow my local webserver (localhost) to read and write the /etc/network/interfaces file on a linux system (ubuntu).
The data manipulation of the file is done, I just need to know the best way of granting www-data the permission to do it.
I guess I could first log in as root and set permission for all to edit the file (not a big security risk since it is a mediaplayer and won't be accessed by any other user).
I could also do some nifty grouping of the user, I guess... not so seasoned with these linux things.
Anyone have a good suggestion, or input on why my suggested method is bad?
I don't know why would you want to do this, but generally groups are handy for this:
You create a new group, for example networking
then you change the group of the file to this new group (and check that it has g+rw permission)
finally you add www-data user to the networking group.
(And possibly relog, since permissions are often cached; this may not be needed for www-data)
I'm trying to reimplement an existing server service in Node.JS. That service can be compared to a classic FTP server: authenticated users can read/create/modify files, but restricted to the permissions given to the matching system user name.
I'm pretty sure I can't have Node.JS run as root and switch users using seteuid() or alike since that would break concurrency.
Instead, can I let my Node.JS process run as ROOT and manually check permissions when accessing files? I'm thinking about some system call like "could user X create a file in directory Y?"
Otherwise, could I solve this by using user groups? Note that the service must be able to delete/modify a file created by the real system user, which may not set a special group just so that the service can access the file.
Running node as root sounds dangerous, but I assume there aren't many options left for you. Most FTP servers run as root too, for the same reason. Though, it means you need to pay a severe attention to the security of the code you are going to run.
Now to the question:
You are asking whether you can reimplement the UNIX permissions control in node.js. Yes you can, but Should Not! It is almost 100% chance you will leave holes or miss edge cases Unix core has already taken care of.
Instead use the process.setuid(id) as you mentioned. It will not defeat concurrency, but you need to think of parallel concurrency rather than async now. That is an extra work, but will release you of an headache of reinventing the Unix security.
Alternatively, if all of the operations you want to carry on filesystem involve shell commands, then you can simply modify them to the following pattern:
runuser -l userNameHere -c 'command'
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.