| 1 |
On Sun, Nov 12, 2006 at 08:43:55AM -0600, Mike Doty wrote: |
| 2 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 3 |
> Hash: SHA1 |
| 4 |
> |
| 5 |
> Harald van Dijk wrote: |
| 6 |
> > On Sun, Nov 12, 2006 at 04:56:33AM -0500, Mike Frysinger wrote: |
| 7 |
> >> On 11/12/06, Harald van Dijk <truedfx@g.o> wrote: |
| 8 |
> >>> On Sun, Nov 12, 2006 at 04:34:25AM -0500, Mike Frysinger wrote: |
| 9 |
> >>>> On 11/12/06, Peter Volkov (pva) <pva@g.o> wrote: |
| 10 |
> >>>>> The possible solution is to add virtual/editor ebuild |
| 11 |
> >>>> this is a horrible idea |
| 12 |
> >>>> |
| 13 |
> >>>> why not modify sudo to not filter the EDITOR env var then there is no |
| 14 |
> >>>> more problem |
| 15 |
> >>> Except for a gaping security hole. |
| 16 |
> >> pulling a ciaranm here huh ? if a guy has access to `sudo`, then |
| 17 |
> >> having a modified environment isnt going to make much difference |
| 18 |
> > |
| 19 |
> > sudo can be configured to only allow access to a select few applications. |
| 20 |
> > Allowing arbitrary EDITOR settings completely bypasses this. |
| 21 |
> so force EDITOR to something "secure" (infra uses rvim) |
| 22 |
|
| 23 |
rvim is less insecure than vim, but isn't secure if called as root, nor are |
| 24 |
most editors. If you can choose to edit other files than those specified on |
| 25 |
the command line, you can edit the boot scripts, and do anything after that. |
| 26 |
|
| 27 |
Anyway, if you have something safe (even if it's only /bin/false), forcing |
| 28 |
EDITOR to it would be good, but I do not believe sudo has an option for |
| 29 |
this. You can remove variables from the environment, but not add them. |
| 30 |
There is a special case for visudo, but that's not handled via the |
| 31 |
environment. And if there is no way to force EDITOR to something safe, |
| 32 |
unsetting it (the current situation) is the next best thing. |
| 33 |
|
| 34 |
> but really, |
| 35 |
> visudo, vipw, crontab.... these can all be exploited to gain root access |
| 36 |
> thus making it silly to try to prevent in these cases. |
| 37 |
|
| 38 |
Obviously you shouldn't allow access to such programs to users that are not |
| 39 |
completely trusted. This isn't about such programs. For example, in ufed, I |
| 40 |
used to read the PAGER variable (if you believe that is significantly |
| 41 |
different, please explain) to display the help. Since sudo clears it, ufed |
| 42 |
is usable even when it's not possible to display the help, and ufed can't |
| 43 |
do anything other than edit /etc/make.conf, it would be safe to allow it to |
| 44 |
run via sudo (emerge --ask should of course be used if ufed can be run, but |
| 45 |
that's a separate issue). That's the kind of thing that would no longer be |
| 46 |
safe. |
| 47 |
-- |
| 48 |
gentoo-dev@g.o mailing list |
Archives