happenings last night
elaine forbes
elaine at fwsystems.com
Fri Feb 14 10:41:46 GMT 2003
On 13 Feb 2003 01:01:13 +0100 (unchecked - local sync NTPstrat4)
Auke Kok <auke.kok at planet.nl> did inscribe thusly:
>
>
> sorry for the lengthy text, but please read along if you were not
> there:
Sounds great, here are the things I've been generally concerned about
with lunar the way it stands.
Using the shell, especially with all the `cmd $ARG` things we do is
giving the semi-trusted data to a root-shell. The trust is that non of
our devs will embed shell metas into a module or url. -- I'd just rather
not do it.
Specifically I looked at this when I needed to develop a tracking system
for csm and found that urls formed http://host/data?var=value breaks a
number of things in the scripts.
I think tchan has (probably correctly) suggested that URNs are more
appropriate for the moonbase -- I'm going to belay that for the moment.
Ok so this is at some level a security issue, It'd be trivially easy
for any lunar developer to put a root exploit into a module -- while I
don't think any of us would do that, and the CVS logs would make
covering tracks difficult, I'd still rather this not be an issue.
As a second-level thing, it is possible (I'm *not* saying likely) that a
source-site could trick a lunar developer into using urls that would
exploit our shell scripts.
I haven't found any 'second-level' ways to exploit this -- that is aside
from the install-scripts could a source-site convince the lunar scripts
to execute atacker-chosen code, while maintaining innocent-looking urls.
However I'm not sure it can't be done.
Fixing
Lunar2
One way (and I think the better way) to fix this is to move to a
'stronger' programming language. lunar2 in ruby will give us both the
strength of perl style tainting to prevent data from ever being allowed
into a shell, as well as a better solution to dropping privelige.
Lunar bash
What's at hand now, dropping privs in bash has at least a few gotchas.
1. su only inherits persistent variables (e.g. export) so we can't
simply run
...
su unprivuser # executes a subshell
more commands
2. even so we'd first have to do something like
for i in `set` do
export $i
done
And I'm not sure that would work properly, it's certainly ugly if you
try it at the cmd prompt.
Elaine
More information about the Lunar-dev
mailing list