strange pam_selinux behavior

strange pam_selinux behavior

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


With DSSP (the mcs policy model) in Fedora i have to modify
/etc/pam.d/sshd to allow users to login with SSHD

Fedora ships with:

session    required     pam_selinux.so open env_params

I suspect that this "env_params" option is used to allow users to
specify the role/level to login with (ssh joe/bla.role/s0:c232@localhost
)

However the env_param option confuses pam_selinux with DSSP, and does
not allow the user to login (if i remove "env_params" then users login
just fine):

> ssh kcinimod@localhost Unable to get valid context for kcinimod

> Mar 23 18:52:38 void sshd[19512]: pam_selinux(sshd:session): Open
> Session Mar 23 18:52:38 void sshd[19512]:
> pam_selinux(sshd:session): Username= kcinimod SELinux User=
> wheel.id Level= s0-s0:c0.c1023 Mar 23 18:52:38 void sshd[19512]:
> pam_selinux(sshd:session): Selected Security Context
> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 Mar 23 18:52:38 void
> audit[19512]: USER_ROLE_CHANGE pid=19512 uid=0 auid=1000 ses=14
> subj=sys.id:sys.role:sshd.sshd.subj:s0 msg='pam:
> default-context=wheel.id:wheel.role: wheel.subj:s0-s0:c0.c1023
> selected-context=wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023
> exe="/usr/sbin/sshd" hostname=::1 addr=::1 terminal=ssh
> res=failed' Mar 23 18:52:38 void sshd[19512]:
> pam_selinux(sshd:session): Failed to translate security class
> context. Invalid argument Mar 23 18:52:38 void sshd[19512]:
> pam_selinux(sshd:session): Security context
> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 is not allowed for
> wheel.id:wheel.role:wheel.s ubj:s0-s0:c0.c1023 Mar 23 18:52:38 void
> sshd[19512]: pam_selinux(sshd:session): Unable to get valid context
> for kcinimod


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;

So what is going on here? What breaks "env_params". Without
"env_params" i can login just fine

Also note this line:

> pam_selinux(sshd:session): Security context
> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 is not allowed for
> wheel.id:wheel.role:wheel.s ubj:s0-s0:c0.c1023

That does not make sense to me

- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW8tk0AAoJECV0jlU3+Udp+wgL/2inFtBIsQ/Wb0cIeID8lo4a
TQPRtfYeLShDbSWn7Bf2dERrk3xRmI0W7ER83OXazduroTIpHi4o5L1ORhSbAc0z
13DVCzxR+8OfuVywmiqftJpthuJ+Gwh9xXmiy0BGwCBngHVeoBRS4UDTKoe2/VkZ
ZiDewHNMAwsw5bR5c5wbUQxW+VGn1JWjxasJPSC8MfXZTXfPZbD1/4/wyyT76u79
KnooJGtiUX0fiAODmV9rHDfuGXPJxqQkwrG3Abxf0utGuJhLxrHCDxKWAFKioVf4
lRnMU3sA5PFbq+MliSbhg693CTIyjMr6Np+8ezHsbkBFMxiSKBb7hDv+E8bTKG6e
hfVkdFSwmy7Gwv/tC6dBb6DIzexESRofORQmws8jrOdKfTI4LNFK6RLMEJJeBzox
0PNoD8eqKayXiPwGQwwWfBSfP7x3Q8giDglBQZeNNg94GyGHVlCDC4WHB6MXGm3/
Zuz7tFktBA8mjKVWi/Wzh+630KL5WERMd9VfJL/ZMw==
=ddJD
-----END PGP SIGNATURE-----

Re: strange pam_selinux behavior

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW8uExAAoJECV0jlU3+UdpAeML/2jEcDzPDAs6zQlDg3EIk4bg
Dtrs3YD5xVyFH6EyheiG5ZZQBDqge0b5jY3YX0l5eabGyjSI4yTvQOSwUTDtHwqR
NQcZQCKWYE/gA72uRjqok7pxHBj5B84TM8SwVc12xAgs3znyy4yHZjlGFmq0VGXO
K9dn6hDvHK6Hk3p8FhnLvumB+Xd6VZ6Ju76JaKSdA19OQ8tYhN7wMvvYEpAAMNJy
Qh+EMPYkMZfcqemru8A7jZ40wh+pb9XuqZCiE2JtW0F1PpC2Aa6RKlwt79de52fB
AAFn6vD/EPlnDksgFhOn+9bUKtT+/zGA4gaflDLtmv3Z2K6U3txHxMIZOhD3XDc6
/pjcIo2gu0cA7gP1r6jkC2dX3uZzx2BHu00e8ilXuI90nXI51nUoi6HzBDVg6Tdd
fnHrAvkl4qJJCRvNXCRDIUxbOecIuwWbVoHRZJWR/0q2TOIIujPzhYsE0dmzPAif
rmygoDv2H6sNKxqaENT1xZlstkSItRuIeeE31q3Rzw==
=gYpm
-----END PGP SIGNATURE-----

Re: strange pam_selinux behavior

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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?



- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW8uJxAAoJECV0jlU3+UdpfKUL/3NL9x8SmNR1RkikgOrv/ATY
gm0ZVACiObMmUoPLaqdl8F5zPUrT31JMv/OAsJcRgtl1QADTpPM+pTmGMzKsoqKE
5aF3QjZ3yhtrhTUsgGGhYQwumdzz9YBnqlHHT8UTz+GPAKDrhgIrQuK83fcN3dpG
02r6CaflD+1WK/5HTj0mzxg02EzdiJ0QSIAoJRcEy41hUuGb3Xfp9RopFJZvtFgi
ZpB+wwGQTveDTUO+Xp5xzg3YAQIwBXY3yKrb+Bg5sumz+QSyf2d/m2DxO29FxXth
tzsBcez8+VZ1K9wTVv03JCIg/JagoqcWu2zOdOM5pXCCy+px+rrbwISy6cHAGK4V
r2fro2Bisuz0ZSiKRYe/19RQ6SpB35ZG/0DpJH3fdLnZfZk/UqTIOrnn31P4rfLL
lA0pjtafrResaJmPUo8NPDXIQTU6PlCpFg8P30iW89d86aWZnH2F86Gpqk2uAzaP
sJIW5jf+XmFy9U2h6lf8CrxGM3tx0nQlBSAlP5vvZg==
=biHz
-----END PGP SIGNATURE-----

Re: strange pam_selinux behavior

[Stephen Smalley]

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

Re: strange pam_selinux behavior

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.

- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW8unrAAoJECV0jlU3+UdpmGMMAJjJRrkXGGT6bmsqrqwKGes7
YlSgTMVUZi1ncsBLoq6wVhV+HHATOj9IOaWXbT0k+bsPv/2xPEk0Tr+TV6Pq7C+v
xfbspTJYW91wKloa7GKE8W+869y/7mwq8BGUJcaeoJy3WktsClV85ZTKL5RNcoaV
DKt3FrkJbvBjzcy7nONqYUJQKXHdgQhsAzMmy2rgZRUeH9CrTVb3/MVCjHTkA9H1
26Euzu2LqUK5R/u19AgtJwqz3peSe4NWsM40z5m7PjrfURQXX8Yd43jGN79Y54PD
ptJ38BUXaPI2H3eRs9gLgh+ewNrxdm2P8wST80fXfrirPxVscxDmk4jrr72hGi0/
jgqM2WZktypEOoZFirfpmHA86AUeZHR//cuvtoyfirYJv3/shmmWPHGDZyeqeX5H
FDqtMIgRahNbayJu7gLgkEVSnT5DVZATyKOgm3CIxyOlVAOaAgC6E7YIaL4LBFA+
98S7Ehf62ArgQ8RPUSFkJO7wPlJHacLUofQqNKt83w==
=DsF5
-----END PGP SIGNATURE-----

Re: strange pam_selinux behavior

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

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.

- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW8vFeAAoJECV0jlU3+Udp/usMAJDYGv2ASDNGxguiHzpewouk
AiljmBEouR24DzPH7np9kEphvDFfKHoGnWP2F2C9Fkf8M9aVdZtnKwmSRYEqGD0W
ku0w6V++zio2ua+RL2mbUYsPidDOXQL4uA9wJZjczYgIZbcSQqf1kE0NQ6fy9nqh
APLqf3UtXTUS0qHijXMJPLFCJe1AzLpQJ+QouMsFJl1W0yCAfjiV3idp83v9pB0d
YmJwLN9lY/jxVyDmvELOZwDpqjHl2Yh3xbRHNblXZjY4wzuUGgQzmKqBoAjy92tj
h9uOtdc9xOmkcV9nuiDh7uBbWfy94PB9MFaGBzF31cXzD2Cf21VR8G/K909IlHtQ
SBeai/q4G8yRyfYfynV/9VsaXA9wObKFUdrGUPtVRTKOqy1wRA61gvpnxDxa4DRe
S/rOTWVloV4L4L6Xq11YOdo6rJ1ptSSgIRO+/hg7lCTJlZ5HhckNwqNGih9mCK0a
MFWwmfXyITSIV1gEgyg871KgBdp/IlQqpc+9/62FxQ==
=hXMR
-----END PGP SIGNATURE-----

Re: strange pam_selinux behavior

[Miroslav Grepl]

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.

Re: strange pam_selinux behavior

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/24/2016 02:14 PM, Miroslav Grepl wrote:

<snip>

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

not quite right:

It now longer shows this: "Failed to translate security class context"

So that part seems to have been fixed by adding the access vector

however this error is still the same:

> pam_selinux(sshd:session): Security context
> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 is not allowed for
> wheel.id:wheel.role:wheel.s ubj:s0-s0:c0.c1023 Mar 24 13:43:03 void
> sshd[14723]: pam_selinux(sshd:session): Unable to get valid context
> for kcinimod

So looking at the code:

> src_context = context_new (src); dst_context = context_new (dst); 
> context_range_set(dst_context, context_range_get(src_context)); if
> (debug) pam_syslog(pamh, LOG_NOTICE, "Checking if %s mls range
> valid for  %s", dst, context_str(dst_context));
> 
> retval = security_compute_av(context_str(dst_context), dst, class,
> bit, &avd); context_free(src_context); context_free(dst_context); 
> if (retval || ((bit & avd.allowed) != bit)) return 0;
> 
> return 1;

it appears that security_compute_av returns bad. But i can't figure
out how to reproduce that with "compute_av":

# compute_av wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023
wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 process

allowed = { fork sigchld sigkill signull signal getsched setsched
setpgid getattr setfscreate }

This works fine with stock fedora policy BTW. this seems to be a DSSP
specific issue. I am wondering if my policy has a bug somewhere...


- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW8+qDAAoJECV0jlU3+UdpQbUL/1PA7BjO9N304QRpvXxXuYlg
0Ev2lOj6Q9uJL/HQzuv7YdJJ1bGAiRcKY7VY402vnqR5fA8xbDGhSWou9gxtT3V6
MXEJRNCCT92x1kWcGncDZk7G1VjNeqbmwWj2nbKjt0e7dyMnymRcvtanNwrIE35i
GVkX73EIj+9FKUFSneouoQJLjUaV08VWGMg0KTFsvO8xeWR6JfogZE5FMDwxjypa
+Gd1NK6K8SHOSI+tGLeRcipGkYdTKRgG8VmF7En/zpEOOn9G+4S/Mx62O3EYCV9O
Ue/mTuwDOjipliKS/S7GPveQnU4pWI9JWpmRNdqLvjVikXymLd5Hfs8pc9m4WOtG
A7Q6mLTm85s/+YNkPGWIgWo/+Uo6LHar2oLCJdMNv6wiA7BmYQ1xZt4C4Gylv6vL
uxuuW2LzfLt5F3UfH7ScsSVGfDivztuIgugtMreQhrajhRvF+25lGuIgykl9nSZP
+hQP6W43CsbNbdG9i7dIUd2AVDmre86/CMvWTvUKwQ==
=Nkx5
-----END PGP SIGNATURE-----

Re: strange pam_selinux behavior

[Miroslav Grepl]

On 03/24/2016 02:24 PM, Dominick Grift wrote:
> On 03/24/2016 02:14 PM, Miroslav Grepl wrote:
> 
> <snip>
> 
>>>
>>> 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?
> 
> 
> not quite right:
> 
> It now longer shows this: "Failed to translate security class context"
> 
> So that part seems to have been fixed by adding the access vector
> 
> however this error is still the same:
> 
>> pam_selinux(sshd:session): Security context
>> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 is not allowed for
>> wheel.id:wheel.role:wheel.s ubj:s0-s0:c0.c1023 Mar 24 13:43:03 void
>> sshd[14723]: pam_selinux(sshd:session): Unable to get valid context
>> for kcinimod
> 
> So looking at the code:
> 
>> src_context = context_new (src); dst_context = context_new (dst); 
>> context_range_set(dst_context, context_range_get(src_context)); if
>> (debug) pam_syslog(pamh, LOG_NOTICE, "Checking if %s mls range
>> valid for  %s", dst, context_str(dst_context));
> 
>> retval = security_compute_av(context_str(dst_context), dst, class,
>> bit, &avd); context_free(src_context); context_free(dst_context); 
>> if (retval || ((bit & avd.allowed) != bit)) return 0;
> 
>> return 1;
> 
> it appears that security_compute_av returns bad. But i can't figure
> out how to reproduce that with "compute_av":
> 
> # compute_av wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023
> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 process
> 
> allowed = { fork sigchld sigkill signull signal getsched setsched
> setpgid getattr setfscreate }
> 
> This works fine with stock fedora policy BTW. this seems to be a DSSP
> specific issue. I am wondering if my policy has a bug somewhere...

That's my point. If it is a bug in your policy or there is a bug related
to CIL. I can try to install your DSSP policy and check it.

> 
> 
> 

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

Re: strange pam_selinux behavior

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/24/2016 02:30 PM, Miroslav Grepl wrote:
> On 03/24/2016 02:24 PM, Dominick Grift wrote:
>> On 03/24/2016 02:14 PM, Miroslav Grepl wrote:
>> 
>> <snip>
>> 
>>>> 
>>>> 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?
>> 
>> 
>> not quite right:
>> 
>> It now longer shows this: "Failed to translate security class
>> context"
>> 
>> So that part seems to have been fixed by adding the access
>> vector
>> 
>> however this error is still the same:
>> 
>>> pam_selinux(sshd:session): Security context 
>>> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 is not allowed
>>> for wheel.id:wheel.role:wheel.s ubj:s0-s0:c0.c1023 Mar 24
>>> 13:43:03 void sshd[14723]: pam_selinux(sshd:session): Unable to
>>> get valid context for kcinimod
>> 
>> So looking at the code:
>> 
>>> src_context = context_new (src); dst_context = context_new
>>> (dst); context_range_set(dst_context,
>>> context_range_get(src_context)); if (debug) pam_syslog(pamh,
>>> LOG_NOTICE, "Checking if %s mls range valid for  %s", dst,
>>> context_str(dst_context));
>> 
>>> retval = security_compute_av(context_str(dst_context), dst,
>>> class, bit, &avd); context_free(src_context);
>>> context_free(dst_context); if (retval || ((bit & avd.allowed)
>>> != bit)) return 0;
>> 
>>> return 1;
>> 
>> it appears that security_compute_av returns bad. But i can't
>> figure out how to reproduce that with "compute_av":
>> 
>> # compute_av wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 
>> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 process
>> 
>> allowed = { fork sigchld sigkill signull signal getsched
>> setsched setpgid getattr setfscreate }
>> 
>> This works fine with stock fedora policy BTW. this seems to be a
>> DSSP specific issue. I am wondering if my policy has a bug
>> somewhere...
> 
> That's my point. If it is a bug in your policy or there is a bug
> related to CIL. I can try to install your DSSP policy and check
> it.
> 
>> 
>> 
>> 
> 

Heres a brief screencast that attempts to explain the issue

https://www.youtube.com/watch?v=kx0zEreMjTA


- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW8/MfAAoJECV0jlU3+UdpUi0L/0Tppj4qTkief2gYenLz9FI/
1fyrXJXmyzphLU7texSu4N6u9YsYqcBql7fkFoV6lB6IwPSyp/gN6d7yI5bdIPbJ
ouKXX8+3j4hwazomWxbuvy7N7/+Mnk87PWe4W8Q4VK5RxDETHfqGzQtGI4dVbfJB
eCYHGGhcRxlCYdJ4GOLetxWk7qcPhVtn7FH/SqmC985iBYAK4SZilb6Xequ2kqGc
OrNG/zBXdGhGgcqOh99hP1HoVirk7QEu8sTmUoaIl/3dTQnGSBDBoQr0w4G38M3l
FDWGjyoT5kmxOD3V74ecUDBEe7rIcmOiDSsQoUFirnR7ysj00vI/IAU05XNKbpUd
7/1f4kKis7VpNZN5YHqXxTImtOG4yBARY9jtWlFuCe5IsdN1Ltg/tmYXMUCZ+FhZ
JpuwRfWw/RpXOqF3PLi1AX/6Zd0Kv5lXO3D3xxeUh9qxjOYGbcr/DbeoYZFRAdJ+
ZGDIKX03QBHgEW1TWIrpVeg7pTgyZDnnyqbTkGMVlQ==
=/Kur
-----END PGP SIGNATURE-----

Re: strange pam_selinux behavior

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/24/2016 02:30 PM, Miroslav Grepl wrote:
> On 03/24/2016 02:24 PM, Dominick Grift wrote:
>> On 03/24/2016 02:14 PM, Miroslav Grepl wrote:
>> 
>> <snip>
>> 
>>>> 
>>>> 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?
>> 
>> 
>> not quite right:
>> 
>> It now longer shows this: "Failed to translate security class
>> context"
>> 
>> So that part seems to have been fixed by adding the access
>> vector
>> 
>> however this error is still the same:
>> 
>>> pam_selinux(sshd:session): Security context 
>>> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 is not allowed
>>> for wheel.id:wheel.role:wheel.s ubj:s0-s0:c0.c1023 Mar 24
>>> 13:43:03 void sshd[14723]: pam_selinux(sshd:session): Unable to
>>> get valid context for kcinimod
>> 
>> So looking at the code:
>> 
>>> src_context = context_new (src); dst_context = context_new
>>> (dst); context_range_set(dst_context,
>>> context_range_get(src_context)); if (debug) pam_syslog(pamh,
>>> LOG_NOTICE, "Checking if %s mls range valid for  %s", dst,
>>> context_str(dst_context));
>> 
>>> retval = security_compute_av(context_str(dst_context), dst,
>>> class, bit, &avd); context_free(src_context);
>>> context_free(dst_context); if (retval || ((bit & avd.allowed)
>>> != bit)) return 0;
>> 
>>> return 1;
>> 
>> it appears that security_compute_av returns bad. But i can't
>> figure out how to reproduce that with "compute_av":
>> 
>> # compute_av wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 
>> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 process
>> 
>> allowed = { fork sigchld sigkill signull signal getsched
>> setsched setpgid getattr setfscreate }
>> 
>> This works fine with stock fedora policy BTW. this seems to be a
>> DSSP specific issue. I am wondering if my policy has a bug
>> somewhere...
> 
> That's my point. If it is a bug in your policy or there is a bug
> related to CIL. I can try to install your DSSP policy and check
> it.
> 
>> 
>> 
>> 
> 

This:

> $ compute_av sys.id:sys.role:sshd.sshd.subj:s0
> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 process allowed= {
> transition signal dyntransition } auditdeny { fork sigchld sigkill
> sigstop signull signal ptrace getsched setsched getsession getpgid
> setpgid getcap setcap share getattr setexec setfscreate setrlimit
> setcurrent execmem execstack execheap setkeycreate setsockcreate
> 0xc0000000 }

what is "0xc0000000"? am i missing av perms for process? They seem to
be complete above

- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW8/o0AAoJECV0jlU3+UdpOR8L/AwQbFwlE2yJWMdYoph/Vxar
W40GmPJYadcr6ne75ibMoJ1NAvrrAd4GuDQcivqKA0VcS4M4MkAWqv+9fu0Jx0dC
oLshUEpBhdhoNGMhffFqbpq4BkKfvtxL4mHdfox72jUh9QPeolFu2sHje2kaVoYT
5vZWBj6HM6u1seo+lDgOvOZFNWA34H99tFn4lRjJWXhXxCVnKCvDW1gX885LI0pA
D3a58aW34PFQobOU+BVXp3YBgC/OtORMRC4Tz+tcygqOQlFHnBVXTZZrvftemG0S
YsH9vB3QfpbQCzvs4M1+UPpjL1PFredgip1LOtys61yuqdat7vyOt8CHj80jUluy
AtuLCZUL6XCFm+2R5HOH29IkidaMifbOu4niUCxTPm+e65YT/rm7605eyqEoX/Zv
LGrh/+xlezXG8CeGMQ54qDfhTa7R3hIjmURq4CSEoQeuXglMI0CU6EFG1lZIJfcj
HUt3KIEW9b6P7asPcXgIpsPPzMUJyFCrrb7GeEw8UQ==
=tzlS
-----END PGP SIGNATURE-----

Re: strange pam_selinux behavior

[Daniel J Walsh]

On 03/24/2016 10:31 AM, Dominick Grift wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 03/24/2016 02:30 PM, Miroslav Grepl wrote:
>> On 03/24/2016 02:24 PM, Dominick Grift wrote:
>>> On 03/24/2016 02:14 PM, Miroslav Grepl wrote:
>>>
>>> <snip>
>>>
>>>>> 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?
>>>
>>> not quite right:
>>>
>>> It now longer shows this: "Failed to translate security class
>>> context"
>>>
>>> So that part seems to have been fixed by adding the access
>>> vector
>>>
>>> however this error is still the same:
>>>
>>>> pam_selinux(sshd:session): Security context
>>>> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 is not allowed
>>>> for wheel.id:wheel.role:wheel.s ubj:s0-s0:c0.c1023 Mar 24
>>>> 13:43:03 void sshd[14723]: pam_selinux(sshd:session): Unable to
>>>> get valid context for kcinimod
>>> So looking at the code:
>>>
>>>> src_context = context_new (src); dst_context = context_new
>>>> (dst); context_range_set(dst_context,
>>>> context_range_get(src_context)); if (debug) pam_syslog(pamh,
>>>> LOG_NOTICE, "Checking if %s mls range valid for  %s", dst,
>>>> context_str(dst_context));
>>>> retval = security_compute_av(context_str(dst_context), dst,
>>>> class, bit, &avd); context_free(src_context);
>>>> context_free(dst_context); if (retval || ((bit & avd.allowed)
>>>> != bit)) return 0;
>>>> return 1;
>>> it appears that security_compute_av returns bad. But i can't
>>> figure out how to reproduce that with "compute_av":
>>>
>>> # compute_av wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023
>>> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 process
>>>
>>> allowed = { fork sigchld sigkill signull signal getsched
>>> setsched setpgid getattr setfscreate }
>>>
>>> This works fine with stock fedora policy BTW. this seems to be a
>>> DSSP specific issue. I am wondering if my policy has a bug
>>> somewhere...
>> That's my point. If it is a bug in your policy or there is a bug
>> related to CIL. I can try to install your DSSP policy and check
>> it.
>>
>>>
>>>
> This:
>
>> $ compute_av sys.id:sys.role:sshd.sshd.subj:s0
>> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 process allowed= {
>> transition signal dyntransition } auditdeny { fork sigchld sigkill
>> sigstop signull signal ptrace getsched setsched getsession getpgid
>> setpgid getcap setcap share getattr setexec setfscreate setrlimit
>> setcurrent execmem execstack execheap setkeycreate setsockcreate
>> 0xc0000000 }
> what is "0xc0000000"? am i missing av perms for process? They seem to
> be complete above
>
> - -- 
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
> Dominick Grift
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQGcBAEBCAAGBQJW8/o0AAoJECV0jlU3+UdpOR8L/AwQbFwlE2yJWMdYoph/Vxar
> W40GmPJYadcr6ne75ibMoJ1NAvrrAd4GuDQcivqKA0VcS4M4MkAWqv+9fu0Jx0dC
> oLshUEpBhdhoNGMhffFqbpq4BkKfvtxL4mHdfox72jUh9QPeolFu2sHje2kaVoYT
> 5vZWBj6HM6u1seo+lDgOvOZFNWA34H99tFn4lRjJWXhXxCVnKCvDW1gX885LI0pA
> D3a58aW34PFQobOU+BVXp3YBgC/OtORMRC4Tz+tcygqOQlFHnBVXTZZrvftemG0S
> YsH9vB3QfpbQCzvs4M1+UPpjL1PFredgip1LOtys61yuqdat7vyOt8CHj80jUluy
> AtuLCZUL6XCFm+2R5HOH29IkidaMifbOu4niUCxTPm+e65YT/rm7605eyqEoX/Zv
> LGrh/+xlezXG8CeGMQ54qDfhTa7R3hIjmURq4CSEoQeuXglMI0CU6EFG1lZIJfcj
> HUt3KIEW9b6P7asPcXgIpsPPzMUJyFCrrb7GeEw8UQ==
> =tzlS
> -----END PGP SIGNATURE-----
> _______________________________________________
> 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.
>
>
I think this check is checking contains.

class context
{
         translate
         contains
}



The idea was you could run a system that only went up to Secret level, then if a user attempted
to login as TopSecret he would be blocked.  I think that is what this check is all about.

Re: strange pam_selinux behavior

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/24/2016 09:42 PM, Daniel J Walsh wrote:
> 


>> 
> I think this check is checking contains.
> 
> class context { translate contains }
> 
> 
> 
> The idea was you could run a system that only went up to Secret
> level, then if a user attempted to login as TopSecret he would be
> blocked.  I think that is what this check is all about.
> 
> 
> 

Thanks, this fixed it!

However, i suspect though that all this stuff is broken. because like
i said i have been using mcstransd since recently and noticed that it
was not checking that access vector at all.

sds found some code in the mcstransd repository that indicates that it
is still is used. Maybe then something is broken? would be nice of
someone could confirm whether anything is actually checking this
access vector or not.

Also this unconditional dependency on a user space access vector is
kind of dubious to me. Would it be possible to do without it?

- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW9FOBAAoJECV0jlU3+UdpPs4L/3yMMsragSJkF/rLTurmDH0F
+pSJY7f5hsvIt41I2nO1UE3XywIx1r7DtSBUenW3VO86ZwUfTAGcqOj2P2YzGRJy
Y7ZDDwVKXR0kKgqJrvPTTiWGRbYR4GX+mwa0OsS6mpnr8oJHA554zAqEcP77xWE+
EvmsObrYFrTRTIbhaK+qG96nRiSthxrZT/mAPz3aPlfOQ4EmVCsOwvepRQg6XbsF
XQArapj1gRiNFkXHvYrPeNjkUaflETZWoZTnuIBtBHLP5giSRGiwUqKkC9+tDoyJ
A15NuAWZCMD1PkVg8L9dyr4J8fahoK00WnoqqjdOnWDOPymjixW7HM2JvleigG85
vCDoqYYDdJi/2G6R8vJucNQzGS8eagi5zvuR2+nltm7/pSgn2ZyHY6IZwvjv0csS
m6asoTIOPoX7HhIZX78KR2ZijrhsLyd63TFc38YnnDDML81Gwg/7DS+SAthX6wzO
dXVCIIUIHQmIa/lVnYj/p57gw5qWfSo1+qldlUdxng==
=nVaV
-----END PGP SIGNATURE-----

Re: strange pam_selinux behavior

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/24/2016 09:42 PM, Daniel J Walsh wrote:
> 
> 
> On 03/24/2016 10:31 AM, Dominick Grift wrote: On 03/24/2016 02:30
> PM, Miroslav Grepl wrote:
>>>> On 03/24/2016 02:24 PM, Dominick Grift wrote:
>>>>> On 03/24/2016 02:14 PM, Miroslav Grepl wrote:
>>>>> 
>>>>> <snip>
>>>>> 
>>>>>>> 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?
>>>>> 
>>>>> not quite right:
>>>>> 
>>>>> It now longer shows this: "Failed to translate security
>>>>> class context"
>>>>> 
>>>>> So that part seems to have been fixed by adding the access 
>>>>> vector
>>>>> 
>>>>> however this error is still the same:
>>>>> 
>>>>>> pam_selinux(sshd:session): Security context 
>>>>>> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 is not
>>>>>> allowed for wheel.id:wheel.role:wheel.s
>>>>>> ubj:s0-s0:c0.c1023 Mar 24 13:43:03 void sshd[14723]:
>>>>>> pam_selinux(sshd:session): Unable to get valid context
>>>>>> for kcinimod
>>>>> So looking at the code:
>>>>> 
>>>>>> src_context = context_new (src); dst_context =
>>>>>> context_new (dst); context_range_set(dst_context, 
>>>>>> context_range_get(src_context)); if (debug)
>>>>>> pam_syslog(pamh, LOG_NOTICE, "Checking if %s mls range
>>>>>> valid for  %s", dst, context_str(dst_context)); retval =
>>>>>> security_compute_av(context_str(dst_context), dst, class,
>>>>>> bit, &avd); context_free(src_context); 
>>>>>> context_free(dst_context); if (retval || ((bit &
>>>>>> avd.allowed) != bit)) return 0; return 1;
>>>>> it appears that security_compute_av returns bad. But i
>>>>> can't figure out how to reproduce that with "compute_av":
>>>>> 
>>>>> # compute_av wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 
>>>>> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 process
>>>>> 
>>>>> allowed = { fork sigchld sigkill signull signal getsched 
>>>>> setsched setpgid getattr setfscreate }
>>>>> 
>>>>> This works fine with stock fedora policy BTW. this seems to
>>>>> be a DSSP specific issue. I am wondering if my policy has a
>>>>> bug somewhere...
>>>> That's my point. If it is a bug in your policy or there is a
>>>> bug related to CIL. I can try to install your DSSP policy and
>>>> check it.
>>>> 
>>>>> 
>>>>> 
> This:
> 
>>>> $ compute_av sys.id:sys.role:sshd.sshd.subj:s0 
>>>> wheel.id:wheel.role:wheel.subj:s0-s0:c0.c1023 process
>>>> allowed= { transition signal dyntransition } auditdeny { fork
>>>> sigchld sigkill sigstop signull signal ptrace getsched
>>>> setsched getsession getpgid setpgid getcap setcap share
>>>> getattr setexec setfscreate setrlimit setcurrent execmem
>>>> execstack execheap setkeycreate setsockcreate 0xc0000000 }
> what is "0xc0000000"? am i missing av perms for process? They seem
> to be complete above
> 
> -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B
> 6B02 
> https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
>
> 
Dominick Grift
>> _______________________________________________ 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.
>> 
>> 
> I think this check is checking contains.
> 
> class context { translate contains }
> 
> 
> 
> The idea was you could run a system that only went up to Secret
> level, then if a user attempted to login as TopSecret he would be
> blocked.  I think that is what this check is all about.
> 
> 
> 

I set out to try mcstransd again today. After doing to searching i
found a clue about the requirement to add accesscheck=1 to
setrans.conf to at least enable checking of the translate av perm.

So i added a few auditallow rules that should catch at least some
checks however: nothing shows up in the logs.

Either i am overlooking something or the mcstransd object manager is
broken
- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW9WEkAAoJECV0jlU3+UdpOuwL/3G0e9fnBRI+u0L/VEa0G1nA
5NgixnksqoZcE396/2AusUCSsSMC2TdxlDBAWQ6wi35nE9tGITcOaUDOQlQqlDJ5
5HE8oZpCLCwpUnfYqI4/+7aGNGUoLuU4ZDzvow/H0o9OQbCwgzVkcFCZDb8tOxpO
T2xd7LdbcqaUY9CP4LoPJIGkXoXrzpzBd/EjI/NydtsLKYK4ylQ7STwWSoVEeoYY
UG1aPcQ47QYIXjiAl8X/f0RUHn9CT4aPKQhvYrevnESHT+MA2s3uiXILPqB278FA
P64iGlAWdiETTblXHYsQFFR6ozqa0k9JbnvYLAnGHSGTu51Ncmcr6xr24HSH8UYI
qq0JZAOjKtzdovsel96hDJTcDPSHBF6J04ZCW74MyYYQTPsl+dPyWzjn30Ypsx0b
wRVww65gkY7LDPbcUXla9ljY3DSQG90audj+MLu76VwkJv7yvhSTE/uhmErqLxQS
IsDH2NaAMNFycgLM1raaVyAZ0ioNmQCkNmn6tYJfcw==
=JhRW
-----END PGP SIGNATURE-----

Re: strange pam_selinux behavior

[Stephen Smalley]

On 03/25/2016 12:02 PM, Dominick Grift wrote:
> I set out to try mcstransd again today. After doing to searching i
> found a clue about the requirement to add accesscheck=1 to
> setrans.conf to at least enable checking of the translate av perm.
> 
> So i added a few auditallow rules that should catch at least some
> checks however: nothing shows up in the logs.
> 
> Either i am overlooking something or the mcstransd object manager is
> broken

Yes, I mentioned the lack of this access check in
http://article.gmane.org/gmane.comp.security.selinux/22011

However, the mcscolor code within mcstrans still does a check of the
context contains permission.  This is only exercised if something calls
selinux_raw_context_to_color() in libselinux, and if one has a
secolor.conf.  That was added for SELinux-aware graphical applications
which display security contexts in order to associate color schemes with
security contexts.

Likely unused in Fedora but may be used in various MLS desktop solutions
built on SELinux.

Re: strange pam_selinux behavior

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 03/25/2016 05:31 PM, Stephen Smalley wrote:
> On 03/25/2016 12:02 PM, Dominick Grift wrote:
>> I set out to try mcstransd again today. After doing to searching
>> i found a clue about the requirement to add accesscheck=1 to 
>> setrans.conf to at least enable checking of the translate av
>> perm.
>> 
>> So i added a few auditallow rules that should catch at least
>> some checks however: nothing shows up in the logs.
>> 
>> Either i am overlooking something or the mcstransd object manager
>> is broken
> 
> Yes, I mentioned the lack of this access check in 
> http://article.gmane.org/gmane.comp.security.selinux/22011
> 
> However, the mcscolor code within mcstrans still does a check of
> the context contains permission.  This is only exercised if
> something calls selinux_raw_context_to_color() in libselinux, and
> if one has a secolor.conf.  That was added for SELinux-aware
> graphical applications which display security contexts in order to
> associate color schemes with security contexts.
> 
> Likely unused in Fedora but may be used in various MLS desktop
> solutions built on SELinux.
> 
> 

Thanks for the info. I really wonder whether its sensible to make
pam_selinux depend in this way on "context contains". Not even sure
how that gets the job done, let alone about any possible alternative
approaches without relying on third party access vectors.

In my policy this breaks modularity. if i decide to exclude the
mcstransd module then the context object class is no longer in policy
and subsequently logins with sshd will break unless the env_params or
select_context options are removed from /etc/pam.d/sshd

But for now i got it "to work" by adding support for this access
vector in my policy, i just need to make a note that env_params and
select_context rely on the presence of msctransd policy

- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJW9WsYAAoJECV0jlU3+Udp4tEL/1D/UQ+Kf0oJZZUaXlj7GCdU
RaM1r3AsJmw14p8Qv2U88+ECu3CbepxroJW7AjPAYnzg5NVVnhy2afv6i0wNioTI
cTuIIoIav6MYNRh/n92ZhxhM18zcvPHVsGG2XWlC/KrMSKqMYiJ0dQyajA9FAd0p
O4kI9GTlcPtQlFAXKNfsLzWhp/x99T99fSjhek3AM6FQYbtk4uZ806PV2Pytn/Rq
LrM/SApdvjQXhwMp+Xiq66iHJOh17VqjP2cD5osnxfUHnPbO8iyjB0PwK3FzX0aW
dBCd4KfZL/1BuUTk6fhbYnIe5FLd2SRMcL0kBSoAkpH/eSOLx3vxsSpOQWKtbZLK
Uyd4Ut4c8Hdy3+NSwb0H8j6tG7ts2mSlWxai/7/YOADJYwT6i11oAHa/QUjptIiu
QmbGjsNcFxlKNsOsm4xDlFZQXvhE1XrPP1Pu6zSgpkMZCgdLEyO8lozNxqewInlo
bsdku9OgXVGqiLzZqTJGNcV85IIWVCO+L3/1jK7TFA==
=Pf5f
-----END PGP SIGNATURE-----