script executables

[Michael Thomas]

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