About this list Date view Thread view Subject view Author view Attachment view

From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Tue 28 Dec 2004 - 16:23:18 GMT

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...

> 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.

>> 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
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

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Tue 28 Dec 2004 - 16:23:39 GMT by hypermail 2.1.3