Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

From bug#132932 (Roy Marples <uberlord@gentoo.org>)
> So as far as I can see the only outstanding thing here is about getting sudo
> put in the up/down scripts. I've chatted with Gentoo Security guys and the sudo
> maintainer, and they think this is a bad idea, so this bug is now being closed
> as FIXED.

Can you reveal me what they said? Why is it bad idea?
Is running root daemon is a better idea?

Can you at least consider adding /etc/conf.d/openvpn.* that have:
DONT_HOOK_OPENVPN=1

So people may use their own scripts to to a do a bad idea, and support
privileges dropping, without patching your scripts? This will allow both side
be happy... Although I think mainline should support privileges dropping...

(In reply to comment #0)
> Can you reveal me what they said?

Well, he just agreed with me that using sudo in this instance is bad

I've cc'ed him on this bug

Basically the up,down.sh scripts may start or stop other services depending on
openvpn which could include things like netmount, ntpd, etc.

Also, note that openvpn runs as the root user until a successfull connection is
made for most configurations.

(In reply to comment #1)
> Well, he just agreed with me that using sudo in this instance is bad

You are not serious...
I am taking this subject very seriously...
Need some better response.

> Basically the up,down.sh scripts may start or stop other services depending on
> openvpn which could include things like netmount, ntpd, etc.

But this is required!!!
I want this behavior be supported...
But why forcing the openvpn daemon run as root?!?!?
You can support his behavior AND run openvpn as non root...
From security perspective it is better... And I don't see what is the down side
of it... I will appreciate any explanation.

> Also, note that openvpn runs as the root user until a successfull connection is
> made for most configurations.

Yes... I will try to work on this issue with John in 2.5... So openvpn will run
the networking commands via scripts... So it will be able to be run as none
root user from start, and user may configure sudouers to allow it to perform
the needed commands and filter them if needed.

Created an attachment (id=86649) [details]
sudo prefix to scripts

Just to be clear, you are proposing that we just prefix the up/down scripts
with something like the attached file.

taviso, could you comment on any problems/pitfalls with this?

Actually, thinking about it, would it not be better to build sudo support into
openvpn for every command it makes? Reasoning - root is required for those
commands anyway (create/destroy tun/tap device, ifconfig and root setup). All
openvpn does is system commands, so a patch for sudo support shouldn't be that
hard. Doing it that make makes this bug moot then :)

(In reply to comment #3)
> Created an attachment (id=86649) [edit] [details]
> sudo prefix to scripts
> 
> Just to be clear, you are proposing that we just prefix the up/down scripts
> with something like the attached file.

TRUE!!!
Simple enough...
Works for all... :)

> Actually, thinking about it, would it not be better to build sudo support into
> openvpn for every command it makes? Reasoning - root is required for those
> commands anyway (create/destroy tun/tap device, ifconfig and root setup). All
> openvpn does is system commands, so a patch for sudo support shouldn't be that
> hard. Doing it that make makes this bug moot then :)

It is!!! This what I want to do in 2.5... (comment#2)
But not prefix each command or execute it directly...
There should be a configurable shell scripts to do each family of commands...
So the user will be able to allow a specific instance of openvpn to control
tun10 and not tun9, or never add route for 2.3.4.5, etc...

In general, sudo shouldnt be used non-interactively, users expect unix
permissions to act as a partition, letting applications elevate their
privileges behind the scenes is a very bad idea.

I think this issue should be resolved by upstream if it's something they want
to support, a suid wrapper specially designed for this purpose or similar would
be best.

(In reply to comment #5)
> In general, sudo shouldnt be used non-interactively, users expect unix
> permissions to act as a partition, letting applications elevate their
> privileges behind the scenes is a very bad idea.

But the need for being root at this stage is a requirement of the integration
with the baselayout... OpenVPN allows you to be notified of some events so you
can do whatever you like in order to handle them.

> I think this issue should be resolved by upstream if it's something they want
> to support, a suid wrapper specially designed for this purpose or similar would
> be best.

suid wrapper is also "letting applications elevate their privileges behind the
scenes".
If you ask me what more secure - use suid or sudo... I am a huge fun of sudo...
Since the user can control what happening.

For example, I can write suid wrapper to manage tun devices... It will be
executed by openvpn and do the trick...
But how can the user make it manage only the right tun interface...?
Now I have to also write a configuration file for this suid wrapper...
And what if I have a bug? You are already in root context can do whatever you
like.

Using sudo is much safer and flexible...
OpenVPN or any process sudo a shell script/user program.
This shell script controlable by the administrator, can impose whatever
restrictions it wants, and hand over the required action to the appropriate
program.

The result is a much secured operation.

Another approach could be that the baselayout will have suid support to allow
none root daemons belonging to XXXX group to perform some basics.

(In reply to comment #4)
> It is!!! This what I want to do in 2.5... (comment#2)
> But not prefix each command or execute it directly...
> There should be a configurable shell scripts to do each family of commands...

Excellent

(In reply to comment #5)
> In general, sudo shouldnt be used non-interactively, users expect unix
> permissions to act as a partition, letting applications elevate their
> privileges behind the scenes is a very bad idea.
> 
> I think this issue should be resolved by upstream if it's something they want
> to support, a suid wrapper specially designed for this purpose or similar would
> be best.

Based on the above statement from our sudo maintainer and security guy AND your
statement that openvpn is working to provide a better solution for this AND the
fact that the default openvpn option is to run as root I'll mark this as
WONTFIX.

As all files in question are in /etc anyway each user is in control of them, so
this shouldn't be that much of an issue.

No...

First, I did not receive your commend regarding adding /etc/conf.d/openvpn.*
with:
DONT_HOOK_OPENVPN=1
So you don't enforce your setting... This should be simple... A simple if will
do at /etc/init.d/openvpn.
And people will be able to specify their own event script in openvpn.conf, and
maybe call yours.

I am waiting for a response specific for this suggestion raised a long time
ago.

Second, It was more polite to wait for a response for the questions I've raised
to the security guy...

His position is quite strange... Since I as a security guy (paid for my
work...) Move people away from the old suid wrappers, into the new controllable
sudo interface.
Calling new for sudo is very strange... but patching the kernel is still
something that many users prefer not to do.

The suid wrappers posses a higher risk than sudo commands.

Security team - now your bug.

(In reply to comment #9)
> Security team - now your bug.

Roy Marples, Why do you refuse to comment my suggestion?

(comment #8)
> First, I did not receive your commend regarding adding /etc/conf.d/openvpn.*
> with:
> DONT_HOOK_OPENVPN=1
> So you don't enforce your setting... This should be simple... A simple if will
> do at /etc/init.d/openvpn.
> And people will be able to specify their own event script in openvpn.conf, and
> maybe call yours.

(In reply to comment #10)
> Roy Marples, Why do you refuse to comment my suggestion?

Because it implies that sudo support is in the scripts - I have already turned
this down. The matter is now for Gentoo Security to decide.

They will either recommend or reject sudo support. They may recommend an
alternative solution in either case.

(In reply to comment #11)
> > Roy Marples, Why do you refuse to comment my suggestion?
> 
> Because it implies that sudo support is in the scripts - I have already turned
> this down. The matter is now for Gentoo Security to decide.

I did not think of it this way.
It only implies a simpler approach of openvpn integration...
Not forcing the user to use gentoo-related openvpn options for openvpn setup.
Allowing this without patching the ebuild each time a new version is out.

Now I am required to supply a new ebuild for the users I support every time to
patch yours... People now use privileges dropping and will continue to use this
feature... The only problem is that although it was supported by the 2.0 series
ebuilds, it is now forced to be not supported and patched. All I asked is to
give users a way out. The variable I suggested is doing exactly that, back to
the 2.0 series environment if requested.

But as you wish... I will wait for the final say regarding this issue...

Misplaced bug

Roy: Saw your fix on bug#181000.

I can use CLIENT_DETECT="no" and close this bug.
But before I do, I think you should rename CLIENT_DETECT to CONFIG_AUTODETECT
so that you will not parse configuration if CONFIG_AUTODETECT is no.

We could have closed this issue long ago and avoid more bugs opened against the
configuration.

Well... Cannot close this bug, as the "client" variable in the init.d script
cannot be modified from outside...
Still cannot drop root privileges and act as a client.

(In reply to comment #15)
> Well... Cannot close this bug, as the "client" variable in the init.d script
> cannot be modified from outside...
> Still cannot drop root privileges and act as a client.

Sure it can. CLIENT_DETECT=no in /etc/conf.d/openvpn and we don't do anything
except run as user/group openvpn/openvpn unless specified in the config.

No.
Look at the "client" variable if it "false" all client functionality is
disabled (the pending behavior).

Ah you really do mean the client variable so we still mark the service inactive
and rely on user defined scripts to re-enter?

(In reply to comment #18)
> Ah you really do mean the client variable so we still mark the service inactive
> and rely on user defined scripts to re-enter?

Yes.
This should be an option.

Please remember what we are trying to accomplish... The EXACT behavior, only
that the daemon run as none root.

The user script will do sudo to the package provided script.

You can add something like FORCE_CLIENT or something.

Added RE_ENTER config variable, which now fixes this.