1 |
On Thu, 22 Dec 2011 14:33:47 -0500 |
2 |
Tanstaafl <tanstaafl@×××××××××××.org> wrote: |
3 |
|
4 |
> Thanks for the explanation Alan... have to do some reading/studying |
5 |
> on this. |
6 |
> |
7 |
> Any good pointers for best practices for this kind of thing? |
8 |
|
9 |
|
10 |
"Best practice" - the two most useless words in all of IT. |
11 |
|
12 |
By definition best practice is always optimized for someone else (or |
13 |
for nothing), never for you. Yes, there are guidelines about security |
14 |
that are very helpful, but step 1 is always to know exactly what YOU |
15 |
are trying to accomplish and what is going to work best for YOU. Your |
16 |
opinion in this is everything, mine is almost irrelevant. |
17 |
|
18 |
Best advice I can give is to read up on the various technologies |
19 |
mentioned in this thread so that you have a good grasp of what they |
20 |
achieve (never mind the detail, think big picture). Usually, what you |
21 |
should do next then becomes quite obvious. |
22 |
|
23 |
|
24 |
> |
25 |
> Thanks again... |
26 |
> |
27 |
> On 2011-12-22 2:21 PM, Alan McKinnon <alan.mckinnon@×××××.com> wrote: |
28 |
> > On Thu, 22 Dec 2011 13:53:43 -0500 |
29 |
> > Tanstaafl<tanstaafl@×××××××××××.org> wrote: |
30 |
> > |
31 |
> >> On 2011-12-22 1:00 PM, Nikos Chantziaras<realnc@×××××.de> wrote: |
32 |
> >>> On 12/22/2011 05:44 PM, Tanstaafl wrote: |
33 |
> >>>> On 2011-12-20 12:19 PM, Nikos Chantziaras<realnc@×××××.de> |
34 |
> >>>> wrote: |
35 |
> >>>>> If you allow someone to edit root owned files, you're |
36 |
> >>>>> practically giving him root access. |
37 |
> >>>> |
38 |
> >>>> Well, yeah, but only on those defined files... |
39 |
> >>> |
40 |
> >>> root access is global. You can't limit it. root is root, the all |
41 |
> >>> powerful Unix being. Period :-) |
42 |
> >> |
43 |
> >> Ummm... then what is the purpose of sudo?? |
44 |
> > |
45 |
> > The purpose of sudo is to provide *fine-grained* control of elevated |
46 |
> > privilege to users and groups. Few people seem to realize just how |
47 |
> > finely this can be controlled, most assume that sudo lets you become |
48 |
> > root and that's it. |
49 |
> > |
50 |
> > As with all things fine-grained, it can get very complex very |
51 |
> > quick. If you want to allow 5 commands to operate on 5 files, you |
52 |
> > have to make 25 allow statements (unless you can use some funky |
53 |
> > wildcard syntax). |
54 |
> > |
55 |
> > |
56 |
> >> |
57 |
> >> If I add the following line to sudoers: |
58 |
> >> |
59 |
> >> %sudoroot |
60 |
> >> ALL=(root)NOPASSWD:/bin/chmod /var/www/localhost/htdocs/* |
61 |
> >> |
62 |
> >> Are you saying that this does NOT limit anyone in the sudoroot |
63 |
> >> group to *only* be able to run the chmod command, and only on |
64 |
> >> files located in /var/www/localhost/htdocs? |
65 |
> > |
66 |
> > Not quite, take out the word "only". When you say only, you exclude |
67 |
> > everything else and that is not true - you might have a second set |
68 |
> > of permissions somewhere else. The line you quoted does exactly what |
69 |
> > you said without the word "only" - it allows the action. Different |
70 |
> > commands and different files are outside the scope of that config |
71 |
> > line |
72 |
> > |
73 |
> >> |
74 |
> >>> Then you put the files in a special group and make them g+w, and |
75 |
> >>> add the affected users to that group. Then they will able to write |
76 |
> >>> to those files. If you want to give them write access to a whole |
77 |
> >>> directory, you put the directory in the group and make it g+w. |
78 |
> >>> This is how it's traditionally been done in Unix for ages, and |
79 |
> >>> it's extremely easy to set up. |
80 |
> >> |
81 |
> >> Yeah, I think I got a little tunnel vision trying to do this with |
82 |
> >> sudo. |
83 |
> > |
84 |
> > Permissions and right of access is hard. Few people know how to do |
85 |
> > it right, and you can't consider just sudo in isolation. |
86 |
> > |
87 |
> > sudo is one command in a whole system and you have to take that into |
88 |
> > account too. The method you use will depend more on everything else |
89 |
> > that machine can do than just on what sudo you can do. |
90 |
> > |
91 |
> > If you need to allow just one single user to access just one single |
92 |
> > directory, you are better off with using Posix ACLS (NOT regular |
93 |
> > owner, group and perms - that almost never works out right for www |
94 |
> > data) |
95 |
> > |
96 |
> > If you have many different users needing all sorts of different |
97 |
> > access to things, you might even consider SE-Linux. Just be |
98 |
> > prepared for huge amounts of customizing. But if it really is what |
99 |
> > you need, SE Linux is worth the sweat. |
100 |
> > |
101 |
> > |
102 |
> |
103 |
> |
104 |
|
105 |
|
106 |
|
107 |
-- |
108 |
Alan McKinnnon |
109 |
alan.mckinnon@×××××.com |