[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: script executables



Stephen Smalley wrote:
On Fri, 2007-01-26 at 13:26 -0500, Stephen Smalley wrote:
On Fri, 2007-01-26 at 10:25 -0800, Michael Thomas wrote:
Stephen Smalley wrote:
On Fri, 2007-01-26 at 09:36 -0800, Michael Thomas wrote:
I'm working on selinux protection for a python script daemon that is started inside of an init.d script. Inside the init.d script the python daemon is invoked as:

python myscript.py --daemon --pid=... --log=...

I'd like to have this process run under its own domain. The worst thing I could do is to relabel python with that domain, but that would just be really bad and sloppy, and not really an option.

Another option that I've gotten to work is to use a wrapper shell script to invoke the python commands. The init.d script invokes the wrapper script, which is labeled with the desired domain.

But I was wondering of there was another way to get myscript.py to run under a specific domain without using an application-specific wrapper. Something like 'sedomainexec myappd_t python myscript.py --daemon ...'
Is the wrapper script my only option?
If myscript.py starts with #!//usr/bin/python -E, then you can just
label the file with an appropriate _exec_t type and have it
automatically transition into its own domain.  SELinux supports domain
transitions on scripts (unlike setuid), although naturally you should
only do that when you trust the calling domain.

You can also use runcon -t to manually launch a program of any kind in a
particular domain.
runcon is exactly what I need.  Thanks!

Unfortunately... It seems that runcon is greedy about parsing command line options. If I use any '--foo' arguments to my command, runcon interprets them as its own arguments and usually throws an error:

# runcon system_u:object_r:httpd_exec_t ls --all
That's a file context, not a process context.

My bad.  But it still showed the problem.

And you can disable option parsing via the usual trick, "--", e.g.
	runcon -t httpd_t -- ls --all

Ah, I see that now in the man page, but not on the --help output of runcon.

but that will fail on the entrypoint permission check.

That explains this:

type=AVC msg=audit(1169836492.684:217): avc: denied { entrypoint } for pid=3542 comm="runcon" name="python" dev=dm-0 ino=3312390 scontext=user_u:system_r:pokerd_t:s0 tcontext=system_u:object_r:bin_t:s0 tclass=file

Couldn't I just add this to my policy file, or is it too dangerous?:

allow pokerd_t bin_t:file entrypoint;

  So you are
better off doing:
	chcon -t httpd_exec_t myscript.py
and letting it do an automatic transition via direct execution, e.g.
	./myscript.py

That won't work in this case, unfortunately. The full command that I'm running is:

/usr/bin/python /usr/bin/twistd --pidfile=/var/run/poker-network/poker-server.pid --python /usr/lib/python2.5/site-packages/pokernetwork/pokerserver.py --...

It's a python script framework (twistd) that is invoking the real application specified on the command line. As before, it wouldn't make sense to label the entire framework. I'm working with the app developers to see if they can work around this and invoke the script directly, but for now I have to assume that it might not be an option.

Although I don't think you want it running directly in httpd_t.
You do have a separate domain for your application, right?

Yes, I have a separate domain for my app. I was just using httpd_t as a test.

Thanks for the help,

--Wart


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]