librelist archives

Problems with Mongrel2 Security Constraints

From:

Erik Osterman

Date:

2011-05-25 @ 19:04

Greetings,

First of all, I appreciate all of the care that has been put into making 
mongrel2 as secure as possible from the get go. Unfortunately, some of 
those checks appear to be misfiring.

1) We're setting up mongrel2 in a fully automated environment. As a 
result, the manner in which tasks are executed does include establishing a
tty. When we try to start mongrel2 with the "-sudo" argument we get the 
following error:

		sudo: sorry, you must have a tty to run sudo

The particular error here is erroneous, because we explicitly have 
disabled "requiretty" in /etc/sudoers, which means sudo can successfully 
be run without a tty (we use this for many Nagios checks already). Thus, 
it seems reasonable to me to let the sudo validation be done solely by  
"sudo" and not by mongrel2. 

2) The other frequent issue we experience is when rebuilding the database 
with m2sh: "(errno: Invalid argument) getlogin failed and no LOGNAME env 
variable, how'd you do that?" 
I've tried exporting "LOGNAME" to "root", but it still fails. 

3) If I run "m2sh load" under sudo (the system command), as a 
non-privileged user (mongrel2), it still complains:

	sudo -u mongrel2 m2sh load -db /opt/mongrel2/mongrel2.db -config 
/opt/mongrel2/mongrel2.conf
 
	[WARN] (errno: No such file or directory) You shouldn't be running things
as root.  Use a safe user instead.

We see the mongrel user in /etc/passwd is not root.
	grep mongrel2 /etc/passwd

	mongrel2:x:104:105::/opt/mongrel2:/bin/bash

And running "id" under sudo shows the sudo execution is valid.

	sudo -u mongrel2 id 
	uid=104(mongrel2) gid=105(mongrel2) groups=105(mongrel2)
	


Please let me know if it's something that I've simply misunderstood!


Erik Osterman
<e@osterman.com>
http://www.osterman.com

On Wed, May 25, 2011 at 3:04 PM, Erik Osterman <e@osterman.com> wrote:

> Greetings,
>
> First of all, I appreciate all of the care that has been put into making
> mongrel2 as secure as possible from the get go. Unfortunately, some of those
> checks appear to be misfiring.
>
> 1) We're setting up mongrel2 in a fully automated environment. As a result,
> the manner in which tasks are executed does include establishing a tty. When
> we try to start mongrel2 with the "-sudo" argument we get the following
> error:
>
>                sudo: sorry, you must have a tty to run sudo
>
> The particular error here is erroneous, because we explicitly have disabled
> "requiretty" in /etc/sudoers, which means sudo can successfully be run
> without a tty (we use this for many Nagios checks already). Thus, it seems
> reasonable to me to let the sudo validation be done solely by  "sudo" and
> not by mongrel2.
>
> 2) The other frequent issue we experience is when rebuilding the database
> with m2sh: "(errno: Invalid argument) getlogin failed and no LOGNAME env
> variable, how'd you do that?"
> I've tried exporting "LOGNAME" to "root", but it still fails.
>

It looks like this is in the log_action function; getlogin fails because no
setlogin call has been made (which, according to the man page, normally
happens when you log into a shell).  It seems like it should be able to
correctly read LOGNAME from the environment though.  Zed, any reason to not
fall over to a default ("unidentified" or something) with a warning instead
of a fatal error?


> 3) If I run "m2sh load" under sudo (the system command), as a
> non-privileged user (mongrel2), it still complains:
>
>        sudo -u mongrel2 m2sh load -db /opt/mongrel2/mongrel2.db -config
> /opt/mongrel2/mongrel2.conf
>
>        [WARN] (errno: No such file or directory) You shouldn't be running
> things as root.  Use a safe user instead.
>
> We see the mongrel user in /etc/passwd is not root.
>        grep mongrel2 /etc/passwd
>
>        mongrel2:x:104:105::/opt/mongrel2:/bin/bash
>
> And running "id" under sudo shows the sudo execution is valid.
>
>        sudo -u mongrel2 id
>        uid=104(mongrel2) gid=105(mongrel2) groups=105(mongrel2)
>
>
I think this is due to the fact that sudo doesn't reset login.  We're using
getlogin to see who the current user is, but that doesn't reflect changes to
uid or euid, so it's still pulling out "root".  Interestingly, you can
setlogin to whatever you want (doesn't even have to be a user on the
machine) so long as you do it as a super user.


>
> Please let me know if it's something that I've simply misunderstood!
>
>
> Erik Osterman
> <e@osterman.com>
> http://www.osterman.com
>
>
>
>
>

On Wed, May 25, 2011 at 12:04:30PM -0700, Erik Osterman wrote:
> Greetings,
> 
> First of all, I appreciate all of the care that has been put into making
mongrel2 as secure as possible from the get go. Unfortunately, some of 
those checks appear to be misfiring.
> 
> 1) We're setting up mongrel2 in a fully automated environment. As a 
result, the manner in which tasks are executed does include establishing a
tty. When we try to start mongrel2 with the "-sudo" argument we get the 
following error:
> 
> 		sudo: sorry, you must have a tty to run sudo

Uh, m2sh isn't printing that out, sudo is.  There's nothing in the m2sh
or mongrel2 code that has that error message.  So, go check your sudo
config and make sure that it's really working.

> 2) The other frequent issue we experience is when rebuilding the 
database with m2sh: "(errno: Invalid argument) getlogin failed and no 
LOGNAME env variable, how'd you do that?" 
> I've tried exporting "LOGNAME" to "root", but it still fails. 

Odd, what's the environment setup for this?  Is it some sort of
restricted chroot or similar?

> 3) If I run "m2sh load" under sudo (the system command), as a 
non-privileged user (mongrel2), it still complains:
> 
> 	sudo -u mongrel2 m2sh load -db /opt/mongrel2/mongrel2.db -config 
/opt/mongrel2/mongrel2.conf
>  
> 	[WARN] (errno: No such file or directory) You shouldn't be running 
things as root.  Use a safe user instead.

That's an odd error as well.  I suspect that you've got some kind of
setup for the that causes this to fail:

char *user = getlogin() == NULL ? getenv("LOGNAME") : getlogin();

In the above command, it may be running at mongrel2, but getlogin() or
the LOGNAME environment variables are still set to root.

Based on this, I think you've setup the mongrel2 user or root in some
way where m2sh can't figure out who is actually running the command.

Here's a helpful tip:

Recompile mongrel2 with:

make clean dev && sudo make install

Then, when you run things you'll get insane amounts of debug logging.
That should help you narrow down where things are going wrong in m2sh
and fix it, or report it back to me.


-- 
Zed A. Shaw
http://zedshaw.com/

> Based on this, I think you've setup the mongrel2 user or root in some
> way where m2sh can't figure out who is actually running the command.

I can say that I have seen similar (possibly identical) problems when trying
to launch Mongrel2 from a CentOS 5 init script that gets executed by the
service command. service absolutely rapes the environment and I had to add

LOGNAME=root
export LOGNAME

to every init script to make everything happy. 

On Wed, May 25, 2011 at 10:02:16PM -0700, Nathan Duran wrote:
> > Based on this, I think you've setup the mongrel2 user or root in some
> > way where m2sh can't figure out who is actually running the command.
> 
> I can say that I have seen similar (possibly identical) problems when trying
> to launch Mongrel2 from a CentOS 5 init script that gets executed by the
> service command. service absolutely rapes the environment and I had to add

Ahhh, yes centos does that.  I think maybe older debian too. It's like
they don't want you to run commands. :-)

-- 
Zed A. Shaw
http://zedshaw.com/

On May 25, 2011, at 12:04 PM, Erik Osterman wrote:

> 
> First of all, I appreciate all of the care that has been put into making
mongrel2 as secure as possible from the get go. Unfortunately, some of 
those checks appear to be misfiring.
> 
> 1) We're setting up mongrel2 in a fully automated environment. As a 
result, the manner in which tasks are executed does include establishing a
tty. When we try to start mongrel2 with the "-sudo" argument we get the 
following error:
> 
> 		sudo: sorry, you must have a tty to run sudo
> 
> The particular error here is erroneous, because we explicitly have 
disabled "requiretty" in /etc/sudoers, which means sudo can successfully 
be run without a tty (we use this for many Nagios checks already). Thus, 
it seems reasonable to me to let the sudo validation be done solely by  
"sudo" and not by mongrel2. 
> 

This was my fault! We had a problem in the order of operations whereby 
"requiretty" was disabled after mongrel2 setup and before Nagios checks.

The rest of the issues stand.


Erik Osterman
<e@osterman.com>
http://www.osterman.com