* strange pam_selinux behavior @ 2016-03-23 17:58 Dominick Grift 2016-03-23 18:32 ` Dominick Grift 0 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2016-03-23 17:58 UTC (permalink / raw) To: selinux -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-23 17:58 strange pam_selinux behavior Dominick Grift @ 2016-03-23 18:32 ` Dominick Grift 2016-03-23 18:37 ` Dominick Grift 0 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2016-03-23 18:32 UTC (permalink / raw) To: selinux -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-23 18:32 ` Dominick Grift @ 2016-03-23 18:37 ` Dominick Grift 2016-03-23 19:08 ` Stephen Smalley 0 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2016-03-23 18:37 UTC (permalink / raw) To: selinux -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-23 18:37 ` Dominick Grift @ 2016-03-23 19:08 ` Stephen Smalley 2016-03-23 19:09 ` Dominick Grift 0 siblings, 1 reply; 16+ messages in thread From: Stephen Smalley @ 2016-03-23 19:08 UTC (permalink / raw) To: Dominick Grift, selinux 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... ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-23 19:08 ` Stephen Smalley @ 2016-03-23 19:09 ` Dominick Grift 2016-03-23 19:41 ` Dominick Grift 0 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2016-03-23 19:09 UTC (permalink / raw) To: Stephen Smalley, selinux -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-23 19:09 ` Dominick Grift @ 2016-03-23 19:41 ` Dominick Grift 2016-03-24 13:14 ` Miroslav Grepl 0 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2016-03-23 19:41 UTC (permalink / raw) To: Stephen Smalley, selinux -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-23 19:41 ` Dominick Grift @ 2016-03-24 13:14 ` Miroslav Grepl 2016-03-24 13:24 ` Dominick Grift 0 siblings, 1 reply; 16+ messages in thread From: Miroslav Grepl @ 2016-03-24 13:14 UTC (permalink / raw) To: Dominick Grift, Stephen Smalley, selinux 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-24 13:14 ` Miroslav Grepl @ 2016-03-24 13:24 ` Dominick Grift 2016-03-24 13:30 ` Miroslav Grepl 0 siblings, 1 reply; 16+ messages in thread From: Dominick Grift @ 2016-03-24 13:24 UTC (permalink / raw) To: Miroslav Grepl, Stephen Smalley, selinux -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-24 13:24 ` Dominick Grift @ 2016-03-24 13:30 ` Miroslav Grepl 2016-03-24 14:01 ` Dominick Grift 2016-03-24 14:31 ` Dominick Grift 0 siblings, 2 replies; 16+ messages in thread From: Miroslav Grepl @ 2016-03-24 13:30 UTC (permalink / raw) To: Dominick Grift, Stephen Smalley, selinux 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-24 13:30 ` Miroslav Grepl @ 2016-03-24 14:01 ` Dominick Grift 2016-03-24 14:31 ` Dominick Grift 1 sibling, 0 replies; 16+ messages in thread From: Dominick Grift @ 2016-03-24 14:01 UTC (permalink / raw) To: Miroslav Grepl, Stephen Smalley, selinux -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-24 13:30 ` Miroslav Grepl 2016-03-24 14:01 ` Dominick Grift @ 2016-03-24 14:31 ` Dominick Grift 2016-03-24 20:42 ` Daniel J Walsh 1 sibling, 1 reply; 16+ messages in thread From: Dominick Grift @ 2016-03-24 14:31 UTC (permalink / raw) To: Miroslav Grepl, Stephen Smalley, selinux -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-24 14:31 ` Dominick Grift @ 2016-03-24 20:42 ` Daniel J Walsh 2016-03-24 20:52 ` Dominick Grift 2016-03-25 16:02 ` Dominick Grift 0 siblings, 2 replies; 16+ messages in thread From: Daniel J Walsh @ 2016-03-24 20:42 UTC (permalink / raw) To: Dominick Grift, Miroslav Grepl, Stephen Smalley, selinux 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-24 20:42 ` Daniel J Walsh @ 2016-03-24 20:52 ` Dominick Grift 2016-03-25 16:02 ` Dominick Grift 1 sibling, 0 replies; 16+ messages in thread From: Dominick Grift @ 2016-03-24 20:52 UTC (permalink / raw) To: Daniel J Walsh, Miroslav Grepl, Stephen Smalley, selinux -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-24 20:42 ` Daniel J Walsh 2016-03-24 20:52 ` Dominick Grift @ 2016-03-25 16:02 ` Dominick Grift 2016-03-25 16:31 ` Stephen Smalley 1 sibling, 1 reply; 16+ messages in thread From: Dominick Grift @ 2016-03-25 16:02 UTC (permalink / raw) To: Daniel J Walsh, Miroslav Grepl, Stephen Smalley, selinux -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-25 16:02 ` Dominick Grift @ 2016-03-25 16:31 ` Stephen Smalley 2016-03-25 16:45 ` Dominick Grift 0 siblings, 1 reply; 16+ messages in thread From: Stephen Smalley @ 2016-03-25 16:31 UTC (permalink / raw) To: Dominick Grift, Daniel J Walsh, Miroslav Grepl, selinux 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. ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: strange pam_selinux behavior 2016-03-25 16:31 ` Stephen Smalley @ 2016-03-25 16:45 ` Dominick Grift 0 siblings, 0 replies; 16+ messages in thread From: Dominick Grift @ 2016-03-25 16:45 UTC (permalink / raw) To: Stephen Smalley, Daniel J Walsh, Miroslav Grepl, selinux -----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----- ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2016-03-25 16:45 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-03-23 17:58 strange pam_selinux behavior Dominick Grift 2016-03-23 18:32 ` Dominick Grift 2016-03-23 18:37 ` Dominick Grift 2016-03-23 19:08 ` Stephen Smalley 2016-03-23 19:09 ` Dominick Grift 2016-03-23 19:41 ` Dominick Grift 2016-03-24 13:14 ` Miroslav Grepl 2016-03-24 13:24 ` Dominick Grift 2016-03-24 13:30 ` Miroslav Grepl 2016-03-24 14:01 ` Dominick Grift 2016-03-24 14:31 ` Dominick Grift 2016-03-24 20:42 ` Daniel J Walsh 2016-03-24 20:52 ` Dominick Grift 2016-03-25 16:02 ` Dominick Grift 2016-03-25 16:31 ` Stephen Smalley 2016-03-25 16:45 ` Dominick Grift
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.