From: Herbert Poetzl (herbert_at_13thfloor.at)
Date: Tue 28 Dec 2004 - 17:02:55 GMT
On Tue, Dec 28, 2004 at 05:23:18PM +0100, Enrico Scholz wrote:
> sfrost_at_snowman.net (Stephen Frost) writes:
> >> [... absolute paths vs. resolution with $PATH ...]
> >> using execvp(3) would mean:
> >> * trusting in $PATH that it contains the wanted path (this has to deal
> >> with packaging philosophies also which expect all 3rd party apps
> >> under /opt/<name>) --> /etc/profile.d/* et.al. must be executed
> >> before everything else
> >> * trusting in $PATH that it contains not too much (e.g. no '.'); we are
> >> operating in hostile environments (guest-servers) --> sanity checks
> >> for $PATH are required
> >> * iterating over all elements of $PATH and try execve() there
> >> With execve(2) you do not have these problems and both coding and
> >> runtime-executing is more efficiently.
> > Alright, you've jumped from a performance issue to being concerned
> > about security. So, let's talk about security then-
> > Who's going to run the programs? Are any of them setuid?
> rebooting with 'vshelper' might have a setuid-like effect...
> > What if the root user is running it and *wants* . in his path for
> > some testing work?
> Having '.' in $PATH results in undefined behavior when non-absolute
> programnames are used. I do not want undefined behavior...
to clarify, there are actually three modes in the
current linux-vserver setup/solution:
a) you are on the host system
b) you are inside the vserver (e.g. with ssh)
c) you are basically on the host system but
half way inside the vserver (doing stuff like
starting services, etc)
where a) and b) is of no concern regarding pathes
or permissions, but c) is a big deal if you call
the wrong (i.e. malign) binary ...
> > If a hostile person has root access in the guest server, what if they
> > just replaced the binaries themselves?
> One problem is:
> | $ vserver foo start
> | ...
> | cd /vservers/foo/...
> | mount /blahblub '.'
> When root has still '.' in $PATH (which was set e.g. for the "testing
> work" above), you could give root-access for the host-system to the
> guest-admin also...
> When executing
> | /bin/mount /blahblub '.'
> things are ok.
> > Or created an alias/function in root's .profile? ...
> util-vserver should/must not use anything in the guest-system. Using
> absolute paths is part of the strategy to avoid this.
yes, and unless we 'decide' not to allow to
manage the vserver from the host system, this
will stay an important issue, if we decide (on
public demand, which I doubt) that access to the
vserver from the host system is not allowed, we
can loosen the rules there without reducing the
> >> I do not see an advantage in guessing paths with execvp(3) over and over
> >> again, when they can be determined at buildtime.
> > The problem is that you're not building on every box out there- you're
> > building on one box and then shipping binary files which can't be
> > changed very easily.
> 1. I do not ship binaries
I totally agree with that philosophy, we do not
do binary kernels either ...
> 2. I do not believe into the one-binary-for-all-distributions concept
> It is free software; everybody can recompile it in his/her environement
> or use packages for the used environment/distribution.
> Vserver mailing list
Vserver mailing list