MLS constraint interfaces

[Ted X Toth <txtoth@gmail.com>]

Chad Hanson wrote:
> mls_trusted_object(xdm_xserver_t) won't help this problem, but something
> like mls_file_read_up and mls_file_write_down would be more approriate
> for xdm_xserver_t.
>
> -Chad
>
>   
>> type=AVC msg=audit(1213041678.053:8): avc:  denied  { read } for
>> pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
>> scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
>> tclass=chr_file
>> type=AVC msg=audit(1213041678.432:10): avc:  denied  { write } for
>> pid=2649 comm="Xorg" name="mem" dev=tmpfs ino=3893
>> scontext=system_u:system_r:xdm_xserver_t:s0-s15:c0.c1023
>> tcontext=system_u:object_r:memory_device_t:s15:c0.c1023
>> tclass=chr_file
>>
>> The xserver_common_domain_template seems to have the necessary allow
>> rules (dev_read_raw_memory and dev_wx_raw_memory) for the types so  I
>> create a local module and added:
>> mls_trusted_object(xdm_xserver_t)
>> to deal with the MLS constraint violation but I'm still getting these
>> AVC.What else can it be?
>>
>> Ted
>>
>>     
>
>   
As I said in another post I've added mls interface calls to deal with 
these constraint violations. However I'm concerned about the breath of 
the interfaces in that they cover many classes/types of files when as 
far as I know the X server really only needs multilevel access to 
'chr_file'. Should there be more class specific interfaces?

--
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.