Re: strange pam_selinux behavior

[Miroslav Grepl <mgrepl@redhat.com>]

On 03/23/2016 08:41 PM, Dominick Grift wrote:
> On 03/23/2016 08:09 PM, Dominick Grift wrote:
>> On 03/23/2016 08:08 PM, Stephen Smalley wrote:
>>> On 03/23/2016 02:37 PM, Dominick Grift wrote:
>>>> On 03/23/2016 07:32 PM, Dominick Grift wrote:
>>>>> On 03/23/2016 06:58 PM, Dominick Grift wrote: <snip>
>>>>>> This seems to be the code:
>>>>
>>>>>>> /* we have to check that this user is allowed to go into 
>>>>>>> the range they have specified ... role is tied to an 
>>>>>>> seuser, so that'll be checked at setexeccon time */ if 
>>>>>>> (mls_enabled && !mls_range_allowed(pamh, defaultcon, 
>>>>>>> newcon, debug)) { pam_syslog(pamh, LOG_NOTICE, "Security 
>>>>>>> context %s is not allowed for %s", defaultcon, newcon);
>>>>
>>>>>>> goto fail_set;
>>>>
>>>>
>>>>
>>>>> This seems related:
>>>>
>>>>>> class = string_to_security_class("context"); if (!class) {
>>>>>>  pam_syslog(pamh, LOG_ERR, "Failed to translate security
>>>>>> class context. %m"); return 0; }
>>>>
>>>>> since:
>>>>
>>>>> pam_selinux(sshd:session): Failed to translate security class
>>>>>  context. Invalid argument
>>>>
>>>>> What is a "security class context"?
>>>>
>>>>> Is it choking on the periods in my identifiers?
>>>>
>>>>
>>>> oh sh.. now i get it. It is choking on the "context" security 
>>>> class.
>>>>
>>>> Yes i dont have that "user space" access vector because that 
>>>> seems to be no longer used.
>>>>
>>>> isnt the context security class a "setransd" thing? if so then
>>>> i do not believe that setransd still uses that. So this should 
>>>> probably be adjusted then to not rely on that user space
>>>> access vector?
> 
>>> I still see it in use in mcstrans 
>>> policycoreutils/mcstrans/src/mcscolor.c:	security_class_t 
>>> context_class = string_to_security_class("context");
> 
>>> Whether or not it ought to be used by pam_selinux is a different 
>>> question...
> 
> 
>> Until recently i used mcstransd on one of my systems, and it never 
>> perfomed any checks , that is why i removed that access vector from
>> my policy.
> 
> 
> 
> added the access vector back in but that seems to not make any differenc
> e.

So you are still getting the same error message, right?

> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.
> 

-- 
Miroslav Grepl
Senior Software Engineer, SELinux Solutions
Red Hat, Inc.