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?
--Wart
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.
On Fri, 2007-01-26 at 12:54 -0500, 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.
Of course, this only happens upon direct execution of the script, not when you just pass it as an argument to python.
You can also use runcon -t to manually launch a program of any kind in a particular domain.
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 runcon: unrecognized option `--all' Usage: runcon CONTEXT COMMAND [args] or: runcon [ -c ] [-u USER] [-r ROLE] [-t TYPE] [-l RANGE] COMMAND [args] Run a program in a different security context.
CONTEXT Complete security context -c, --compute compute process transition context before modifying -t, --type=TYPE type (for same role as parent) -u, --user=USER user identity -r, --role=ROLE role -l, --range=RANGE levelrange --help display this help and exit --version output version information and exit
I'll file this in bugzilla.
--Wart
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.
And you can disable option parsing via the usual trick, "--", e.g. runcon -t httpd_t -- ls --all
but that will fail on the entrypoint permission check. 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
runcon: unrecognized option `--all' Usage: runcon CONTEXT COMMAND [args] or: runcon [ -c ] [-u USER] [-r ROLE] [-t TYPE] [-l RANGE] COMMAND [args] Run a program in a different security context.
CONTEXT Complete security context -c, --compute compute process transition context before modifying -t, --type=TYPE type (for same role as parent) -u, --user=USER user identity -r, --role=ROLE role -l, --range=RANGE levelrange --help display this help and exit --version output version information and exit
I'll file this in bugzilla.
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.
And you can disable option parsing via the usual trick, "--", e.g. runcon -t httpd_t -- ls --all
but that will fail on the entrypoint permission check. 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
Although I don't think you want it running directly in httpd_t. You do have a separate domain for your application, right?
runcon: unrecognized option `--all' Usage: runcon CONTEXT COMMAND [args] or: runcon [ -c ] [-u USER] [-r ROLE] [-t TYPE] [-l RANGE] COMMAND [args] Run a program in a different security context.
CONTEXT Complete security context -c, --compute compute process transition context before modifying -t, --type=TYPE type (for same role as parent) -u, --user=USER user identity -r, --role=ROLE role -l, --range=RANGE levelrange --help display this help and exit --version output version information and exit
I'll file this in bugzilla.
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
On Fri, 2007-01-26 at 10:48 -0800, Michael Thomas wrote:
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;
It doesn't make much difference in this case, since it is a script and it isn't particularly privileged (any more so than the caller). But use the refpolicy interface instead: domain_entry_file(pokerd_t, bin_t)
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.
Ok.
selinux@lists.fedoraproject.org
-
Michael Thomas -
Stephen Smalley