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