| 1 |
On Tue, 13 Jan 2009 19:33:14 +0000 |
| 2 |
Mick <michaelkintzios@×××××.com> wrote: |
| 3 |
|
| 4 |
> On Sunday 11 January 2009, Mike Kazantsev wrote: |
| 5 |
> |
| 6 |
> > If blocking every possible user is too much trouble or you wish to |
| 7 |
> > block just firefox, but not wget to http port for _all_ users (not the |
| 8 |
> > same case as emerge from root) you can write a simple SUID wrapper for |
| 9 |
> > firefox binary, which changes group to restricted one (but leaves uid |
| 10 |
> > and home unchanged), |
| 11 |
> |
| 12 |
> Is this like creating a symlink to the original FF binary which you have moved |
| 13 |
> somewhere else? Can you please explain? |
| 14 |
> |
| 15 |
> > then launches true firefox binary, to which only |
| 16 |
> > that group has access. |
| 17 |
|
| 18 |
|
| 19 |
No, it's not. |
| 20 |
|
| 21 |
|
| 22 |
Symlinks aren't made for that purpose, and should be treated just linke |
| 23 |
the object they point to, without messing with anything on the way. |
| 24 |
As a rule, symlink permissions should not be changed, and in most cases |
| 25 |
it's not supported by OS anyway. |
| 26 |
|
| 27 |
What I mean is a wrapper binary. It can be either a native binary file |
| 28 |
(like C compiled into ELF) or a script with SUID interpreter (like suid |
| 29 |
perl). |
| 30 |
|
| 31 |
I haven't tried this trick with firefox myself, but I don't see why it |
| 32 |
shouldn't work here. |
| 33 |
|
| 34 |
|
| 35 |
For example: |
| 36 |
|
| 37 |
--- ff_wrapper.c |
| 38 |
|
| 39 |
int main(int argc, char **argv) |
| 40 |
{ |
| 41 |
/* Set group to 'ff-users' (gid = 400, for this example) */ |
| 42 |
setegid(400); |
| 43 |
setgid(400); |
| 44 |
|
| 45 |
/* Drop root privileges */ |
| 46 |
seteuid(getuid()); |
| 47 |
|
| 48 |
/* Start real firefox */ |
| 49 |
execv("/usr/bin/_firefox", argv); |
| 50 |
} |
| 51 |
|
| 52 |
--- ff_wrapper.c |
| 53 |
|
| 54 |
|
| 55 |
You can compile it with 'gcc ff_wrapper.c -o ff_wrapper'. |
| 56 |
|
| 57 |
Then do: |
| 58 |
|
| 59 |
mv /usr/bin/{,_}firefox \ |
| 60 |
&& chown root:nogroup /usr/bin/_firefox \ |
| 61 |
&& chmod 0750 /usr/bin/_firefox \ |
| 62 |
&& mv ff_wrapper /usr/bin/firefox \ |
| 63 |
&& chown root:root /usr/bin/firefox \ |
| 64 |
&& chmod 6555 /usr/bin/firefox |
| 65 |
|
| 66 |
|
| 67 |
So firefox can only be launched directly by specific group (with gid=400 |
| 68 |
in this example, which should be created for this purpose), and the |
| 69 |
wrapper ensures that when typing 'firefox' every user will be launching |
| 70 |
it as a member of that group. |
| 71 |
After that you can limit this group as you like. |
| 72 |
|
| 73 |
Note that for all this to make sense, no user (firefox user, anyway) |
| 74 |
should belong to the aforementioned group, or they'll be able to run |
| 75 |
'/usr/bin/_firefox' directly, having effective gid that's written in |
| 76 |
passwd (like 'someuser', usually the same as login name with linux). |
| 77 |
|
| 78 |
|
| 79 |
It's a bit more complicated with the scripts (bash, for example), |
| 80 |
because in that case it's an interpreter binary that gets launched |
| 81 |
(i.e. /bin/bash, which then just reads the script), so the interpreter |
| 82 |
should have suid flag, and that's a huge security gap, since every user |
| 83 |
having access to it will be able to abuse root privileges. |
| 84 |
|
| 85 |
There are, however, interpreters like perl, which, granted suid bit, |
| 86 |
will shed all the privileges if the script they're trying to execute |
| 87 |
doesn't have suid bit set on it, but even then there are whole lot of |
| 88 |
things to check, so no one'll be able to abuse the script itself. |
| 89 |
|
| 90 |
|
| 91 |
-- |
| 92 |
Mike Kazantsev // fraggod.net |
Archives