script executables

[Stephen Smalley]

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
National Security Agency