[redhat-lspp] RE: trouble using runcon

[Clarkson, Mike R (US SSA)]

I moved this discussion over from the fedora-selinux-list at redhat.com
list to this list since the discussion is focused more on mls issues.

> -----Original Message-----
> From: Stephen Smalley [mailto:sds at tycho.nsa.gov]
> Sent: Wednesday, May 02, 2007 4:49 AM
> To: Clarkson, Mike R (US SSA)
> Cc: fedora-selinux-list at redhat.com
> Subject: RE: trouble using runcon
> 
> On Tue, 2007-05-01 at 15:38 -0700, Clarkson, Mike R (US SSA) wrote:
> > Stephen,
> >
> > You were right. Adding selinux_validate_context(datalabeler_t) got
me
> > past the problem and I started getting some useful acv denial
messages
> > in the audit log. I can now successfully run my script using runcon
as
> > follows:
> > 	"runcon -u root -r system_r -t datalabeler_t -l s0-s15:c0.c255
> > java 	mls.SimulatedImport.SimulatedDataLabeler $argv[*]"
> >
> > However, if I try to specify a different mls level in the runcon
> > statement it doesn't work. It looks like it fails to kick off the
java
> > process, or at least I can't see the java process running using ps.
> >
> > The command I'm trying to use is this:
> > 	"runcon -u root -r system_r -t datalabeler_t -l s1 java
> > mls.SimulatedImport.SimulatedDataLabeler $argv[*]"
> >
> > I'm not getting meaningful acv messages in the audit log.
Audit2allow is
> > telling me I need to add allow statements to my policy that I
already
> > have. I think that I'm probably violating some MLS constraint (I
find
> > that audit2allow does not give me useful messages when the problem
is
> > that an MLS constraint is being violated).
> >
> > Do either of you have any ideas on what constraint I might be
violating?
> > I already have "mls_process_set_level(datalabeler_t)" in my policy,
and
> > "semanage user -l" and "semanage login -l" both show that root has
the
> > mls range of s0-s15:c0.c255.
> 
> (re-added fedora-selinux-list to cc line)
> 
> audit2allow -a -l should only process avc messages since your last
> policy reload.
> 
> Is that runcon command running in the datalabeler_t domain already or
in
> a different domain (the caller domain)?  If the former, why are you
> specifying -r system_r -t datalabeler_t at all to runcon (vs. just the
> components that are changing)?  If the latter, then the caller domain
> needs mls_process_set_level().

The runcon command is running in the datalabeler_t domain. See comments
below for further explanation. I don't need to specify the -r or -t
flags to the runcon command. I was just experimenting. The only thing
that I'm trying to change is the level with the -l command.

> 
> Also, you'd have to deal with other MLS-related issues, e.g. if you
want
> that java process to be able to write to your tty (at s0), you'd need
to
> give it mls_fd_use_all_levels() to inherit stdin/stdout/stderr and
> mls_file_write_down() to write to the tty.  But ideally you'd be using
> newrole -l s1 instead and let it relabel the tty for you properly.

I had to add two things to get this to work,
mls_fd_use_all_levels(datalabeler_t) and mls_file_write_down(import_t).
I'm confused and concerned about having to add
mls_file_write_down(import_t). This is not a privilege that I want to
give to the import_t domain. Let me back up and further explain my
setup.

I'm currently just prototyping with simulated executables. I have a very
simple c++ Import executable that simply takes a path as an argument and
writes a small text file to that path. I have a simple Java Datalabeler
class that kicks off the Import executable. I have a csh startup script
(datalabeler.csh) that kicks off the java process using the runcon
command. My initial domain is unconfined_t. The datalabeler.csh script
is the entry point into the datalabeler_t domain. The datalabeler_t
domain has the execute_no_trans privilege for both the runcon and java
executable types to allow it to run these while remaining in the
datalabeler_t domain. The import executable is the entrypoint into the
import_t domain. The import executable writes a file of type
import_file_t.

The datalabeler_t domain will have a small amount of code that will be
SELinux aware and will have to be trusted because it will determine what
level the import process is to run at, so giving it extra privileges is
not so much of a problem. The import_t domain will run a very large
amount of legacy code that is not trusted, so giving it extra privileges
like write_down is not good. I start at the s0-s15:c0.c255 level and I
want to run the import_t domain at the s1 level and end up with an
import_file_t type with the s1 level. This is currently working but I
had to give the import_t domain write down privilege. Given that my
datalabeler.csh script uses the runcon command to start the java process
at the s1 level, I would expect that the import_t domain would run at
the s1 level and be able to write the import_file_t file at the s1 level
without needing writedown privilege. Here is the runcon command that I'm
using:
	"runcon -l s1 java mls.SimulatedImport.SimulatedDataLabeler
$argv[*]"

Any ideas on how to fix this so that I don't have to give the import_t
domain writedown privilege?

You mentioned above that ideally I'd be using newrole -l instead. Could
you explain further on how I would use newrole and the advantages of
doing so?

Thanks for your help!

> 
> You may want to take further follow-ups to redhat-lspp list for
> MLS-specific issues.

done

> 
> --
> Stephen Smalley
> National Security Agency