On 27/08/2012 19:38, Sven Vermeulen wrote:
> On Sun, Aug 26, 2012 at 11:57:46AM +0200, Paolo Barile wrote:
>> Hello Sven, first of all, all the denials I wrote here are from
>> enforcing mode.
> Oh that's good then. Would you also happen to get any failures from the
> applications themselves (or error messages you get)? 
>
> Or, in other words, why shouldn't I just dontaudit everything ;) 
>
> Getting the error messages is a very important and often misunderstood part.
> It helps identify the reason why something needs to be allowed (since for
> SELinux policies, we have several interfaces that allow something, but
> depending on the reason why it needs to be allowed, we might need to use a
> different interface) and also document the problem so the fix is easier to
> submit upstream.
Well I only had a policykit crash window. But It disappeared when,
following your suggestion, I've made a rule with  audit2allow only on
the execute denials. But even with that rule the problems of audio card
and powerdevil weren't solved.
This is the rule:
require {
        type policykit_exec_t;
        type bin_t;
        type crond_t;
        type system_dbusd_t;
        class file { execute execute_no_trans };
}

#============= crond_t ==============
allow crond_t bin_t:file { execute execute_no_trans };

#============= system_dbusd_t ==============
allow system_dbusd_t policykit_exec_t:file execute;

>
>>>> Aug 25 18:06:05 dell-studio kernel: [    8.028595] type=1400
>>>> audit(1345917944.027:3): avc:  denied  { search } for  pid=1433
>>>> comm="alsactl" name="root" dev="sda5" ino=1308163
>>>> scontext=system_u:system_r:alsa_t tcontext=system_u:object_r:default_t
>>>> tclass=dir
>>> This sais /root is default_t again. Mine sais:
>>>
>>> ~ # matchpathcon /root
>>> /root   root:object_r:user_home_dir_t
>>>
>>> ~ # grep '/root' /etc/selinux/strict/contexts/files/file_contexts* | grep 
>>> user_home_dir_t
>>> /etc/selinux/strict/contexts/files/file_contexts.homedirs:/root -d 
>>> root:object_r:user_home_dir_t
>> The same gives me nothing.
> You'll need to change the directory from strict to targeted in your case.
>
> The root users' home directory should definitely be mentioned here (just
> checked on a targeted system at work). Is the root user mapped to a
> particular SELinux user?
>
> What does "semanage login -l" say?
Semanage login -l outputs only:
__default__               unconfined_u            
system_u                  system_u

Anyway I think that I "solved" this problem (probably it's rather a
workaround) using the context you wrote: "semanage fcontext -a -t
user_home_dir_t /root". In fact the su delay disappeared.

>
> [... Allowing global_ssp to allow domains access to urandom ...]
>> No, it isn't. I did not enabled it because I'm still not in hardened
>> because I'd want let selinux comletely work before the conversion.
> That's okay. At least we now know that the domain probably needs it. Do you
> only get the denials or also an error?
>
> Wkr,
>       Sven Vermeulen
>
Well, no, all what is related to alsactl is (perhaps) the fact that kde
can't see my audio card.

There is one more problem. As I wrote in the previous mail two folders
in /run are mislabeled: /run/ConsoleKit and /run/console. For the first,
the mislabeling was solved by using the script for the initramfs users
(of course addin restorecon -R /run). But I couldn't relabel permanently
the second dir. I think it's because it belongs to pam, so perhaps it is
created after a login, but the script runs before it. Am I right?
So how can it be solved? Why every boot mislabels these two directories?
I think that if we solve it then we can try to summarize the denials I
have at this point.

Paolo.

Reply via email to