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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
