Re: launching apps at level (MLS) and polyinstantiation

[Darrel Goeddel <dgoeddel@TrustedCS.com>]

Stephen Smalley wrote:
> How about the revised patch below (only including the newrole.c and
> Makefile diffs since the hashtab code is unchanged)?  The changes from
> your patch are:
> - Make sure everything is properly enabled/disabled by USE_PAM and move
> the code into the existing USE_PAM block where appropriate.
> - Call the config file newrole_pam.conf since there could be other
> newrole config files in the future.
> - Distinguish missing config file (ok) from errors during parsing of the
> config file (should abort).
> - Remove the Authenticating <username> message since it could be
> confusing in the case where you are using a pam config that doesn't
> require it and it doesn't really provide any benefit.
> - Improve error checking and handling.
> - Coding style cleanups (indentation, comment style, etc).
> 
> To test, I created a /etc/pam.d/newrole-noauth config that had
> pam_permit.so for its auth module and created
> a /etc/selinux/newrole_pam.conf that mapped one program to
> newrole-noauth.
> 
> The alternative model would be to eliminate /etc/selnux/newrole_pam.conf
> entirely from the equation, and just have newrole look for (test via
> access()) a /etc/pam.d/newrole_<appname> config and use
> newrole_<appname> as the service name if present.

I like this idea.  I haven't had a chance to test this yet, but it looks
to be assuming that the arg to -c is just the command name without any
path info.  Should we strip that down to its basename in case someone runs
'newrole -l secret -c /usr/bin/foo' as opposed to 'newrole -l secret -c foo'?

-- 

Darrel

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.