I moved this discussion over from the [EMAIL PROTECTED] list to this list since the discussion is focused more on mls issues.
> -----Original Message----- > From: Stephen Smalley [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 02, 2007 4:49 AM > To: Clarkson, Mike R (US SSA) > Cc: [EMAIL PROTECTED] > 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 -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
