Clarkson, Mike R (US SSA) wrote:
I've got the following AVC denial message that I can't get past:
type=AVC msg=audit(1180136666.749:225351): avc: denied { write } for
pid=6603 comm="java" name="3" dev=devpts ino=5
scontext=m252_u:system_r:java_t:s15:c0.c255
tcontext=m252_u:object_r:devpts_t:s0 tclass=chr_file
The corresponding output from audit2allow is:
[EMAIL PROTECTED] foo]# audit2allow -i /var/log/audit/audit.log -l -v -r
require {
class chr_file write;
class dir write;
type devpts_t;
type java_t;
type tmp_t;
role system_r;
};
allow java_t devpts_t:chr_file write;
#TYPE=AVC MSG=audit(1180136666.749:225351): COMM="java"
NAME="3" : write
#TYPE=AVC MSG=audit(1180136666.749:225351): COMM="java"
NAME="3" : write
#TYPE=AVC MSG=audit(1180136666.749:225351): COMM="java"
NAME="3" : write
#TYPE=AVC MSG=audit(1180136666.749:225351): COMM="java"
NAME="3" : write
allow java_t tmp_t:dir write;
#TYPE=AVC MSG=audit(1180136666.757:225352): COMM="java"
NAME="hsperfdata_mbean" : write
This is an mls constraint issue because if I use "runcon -l s0 ..." (or
equivalently remove the runcon statement) rather than "runcon -l
s15:c0.c255 ...", everything works fine.
The two things that I would think are needed to allow this are:
allow java_t devpts_t:chr_file write;
mls_file_write_down(java_t)
I've provided both of these. (I recognize that giving java_t write down
privilege is not a good idea. This is just a temporary solution for demo
purposes until we can get all of our domains set up properly.)
Any ideas for what I need to do to get past this AVC denial?
The question is why is your pseudo terminal labeled devpts_t instead of
something like
staff_devpts_t. This is also a case where using newrole would be better
than runcon since newrole will change the context of the controlling
terminal.
Thanks
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
