On 04/17/10 08:13, Jonathan wrote: > I'm trying to work out how many ways there are to increase the permissions of > a user. > > 1: su -: Needs root password and you need to be in the group "wheel". > 2: sudo: You need to be in the group "wheel" or in the /etc/sudoers file, > using your own user password. > I'm not counting gksu and gksudo they are just front ends. > 3: sudoedit: This is the best way to edit text files, it uses the same rules > as sudo.
sudoedit is mainly just a shortcut for "sudo $EDITOR" (plus doing a few things). > 4: Linux "Capabilities" or "caps": Which increases permissions on a > per-file basis. e.g. removing SUID from ping and adding CAP_NET_RAW > to ping. > This is much safer than running the whole program as root. > http://linux.die.net/man/7/capabilities > 5: Policykit: (Give this a read > http://hal.freedesktop.org/docs/PolicyKit/introduction.html ) > 6: Polkit: Is the new name for Policykit, it's a higher version and they do > not talk to each other. > If you run a mixed architecture there is a good chance you will have both. > 8: SUID and SGID: One of the fastest ways to open up a security hole in your > system. Everything above (su,sudo,policykit,polkit) are just sugar for permission bits (owner,group,others+SUID,GUID); attempting to give finer control over the permissions or provide convenience services. > 9: Groups: Lots of groups, but not much information on what > permissions you get. http://en.gentoo-wiki.com/wiki/List_of_Groups > Udev and Fuse use group settings right? The basis of all Linux security scheme is the file permission bits (owner,group,other) and the SUID/GUID bit (ACL is a distinct security scheme, so we're explicitly excluding it here). Everything else is just sugar. If you want to lock everything, just remove the SUID/GUID-bit from all executables in your system (except for a select few) and remove all groups (make sure you know what you're doing though, lots of program won't work if you really do that). Starting from step zero, you can have very fine control over everything. > 7: Access Control Lists: (ACL) Very easy to setup and forget because > Nautilus and others do not list the ACL settings. > A remote windows user configuring a samba share could let more > people read and write to it then Nautilus shows. ACL is largely there for compatibility with Windows' permission scheme, it's a distinct security scheme than Linux. > Did I miss any way of increasing your rights? (not counting security holes) Most security holes in Linux comes from a SUID program that lets untrusted programs into the "trusted-space". > I see that the stable net-misc/iputils (ping) does not use capabilities. > Is this included in the unstable version, or is it planned for the future? > I wish there was a way to run gedit with sudoedit, is there? > I think Polkit support for gedit is planned, does anyone know the bug number? > > Right now my system has all of the above but not Linux "capabilities". > I'm having very hard time working out: > Which users can do what and how. > Which groups can do what and how. > Which files can do what and who can run them. > How the user's status affects what the program can do. All users can modify the permission bits for the files they owned, everything else is governed by the permission bits. Except for root, which has full access to everything. If you want simplify your environment, you can clear all the `group` and `other` permission bits from all files in your computer and everyone (except root) will only have access to files they own. Then you can start adding permissions on case-by-case basis. Too much hassle though, I think. > Is there an all-in-one program for keeping track of all this or do I have to > write one? > > It's very easy for users to set their home folder to other, read, write > and execute. It's not just silly users doing that, but any program running > with the users rights. > There was a buggy program in Ubuntu which set your home folder to other > rwx, I never worked out which one was doing that. the only way the program can chmod a file in your home folder is because the program have the permission to chmod a file in your home folder. The only program that have permission to chmod a file in your home folder is the one run with EUID-root or EUID-owner. The only way a program can be run with EUID root is they are executed by root himself or a SUID-root program. The only way a program can be run with EUID owner is SUID-owner program or program executed by the owner himself. However, I don't think buggy program is the case here. It is much more likely that you accidentally runs chmod on your home folder when you actually want to run it in another directory. > A fast work around was to set the user's home folder to owner root and > make sure that group was set to rwx. Is that safe? You can use this to find all SUID program accesible by your user: find / -perm -u+s -exec ls -l '{}' \; 2> /dev/null I found sudo, although very handy for desktop, is a huge security hole. And is inadequate for any secure system. This is simply because if you run a program as sudo, then in the next five minute you start a malicious program *without* sudo; the malicious program can gain root access by stealing your previous sudo's timestamp (yes, it can steal the timestamp without being explicitly invoked with sudo[1]). Before running a potentially untrusted program, you must explicitly kill your sudo timestamp with `sudo -k` or set sudo to not use timestamp. Better yet, don't use sudo on secure systems. [1] the malicious program only need to invoke sudo on themselves and they get root access without you ever prepending the magic word to the program.
