* SELinux policy regarding LD_LIBRARY_PATH
@ 2011-08-04 12:14 Aaron Sowry
2011-08-04 12:50 ` Sven Vermeulen
2011-08-04 13:09 ` Stephen Smalley
0 siblings, 2 replies; 6+ messages in thread
From: Aaron Sowry @ 2011-08-04 12:14 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
Hi,
It appears that with SELinux enabled, the LD_LIBRARY_PATH environment
variable is not inherited by user processes forked by a root process.
This is on RHEL6.
What is the general SELinux policy regarding LD_LIBRARY_PATH? Is there
any way to change this behaviour? I couldn't find any documentation
regarding this.
Thanks,
Aaron
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SELinux policy regarding LD_LIBRARY_PATH
2011-08-04 12:14 SELinux policy regarding LD_LIBRARY_PATH Aaron Sowry
@ 2011-08-04 12:50 ` Sven Vermeulen
2011-08-04 13:06 ` Aaron Sowry
2011-08-04 13:09 ` Stephen Smalley
1 sibling, 1 reply; 6+ messages in thread
From: Sven Vermeulen @ 2011-08-04 12:50 UTC (permalink / raw)
To: selinux
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
On Thu, Aug 4, 2011 at 2:14 PM, Aaron Sowry <aaron@cendio.se> wrote:
> It appears that with SELinux enabled, the LD_LIBRARY_PATH environment
> variable is not inherited by user processes forked by a root process.
> This is on RHEL6.
>
> What is the general SELinux policy regarding LD_LIBRARY_PATH? Is there
> any way to change this behaviour? I couldn't find any documentation
> regarding this.
>
>
If the fork results in a type transition (say from sysadm_t to mozilla_t),
then the environment is cleaned up (see glibc's AT_SECURE setting).
If you do not want the environment to be cleared, allow noatsecure, like so:
allow sysadm_t mozilla_t:process noatsecure;
Wkr,
Sven Vermeulen
PS Aaron sorry for double post, reply-to went to you instead of mailinglist.
[-- Attachment #2: Type: text/html, Size: 1071 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SELinux policy regarding LD_LIBRARY_PATH
2011-08-04 12:50 ` Sven Vermeulen
@ 2011-08-04 13:06 ` Aaron Sowry
0 siblings, 0 replies; 6+ messages in thread
From: Aaron Sowry @ 2011-08-04 13:06 UTC (permalink / raw)
To: Sven Vermeulen; +Cc: selinux
[-- Attachment #1: Type: text/plain, Size: 422 bytes --]
Sven, Spencer,
> If the fork results in a type transition (say from sysadm_t to mozilla_t),
> then the environment is cleaned up (see glibc's AT_SECURE setting).
>
> If you do not want the environment to be cleared, allow noatsecure, like so:
>
> allow sysadm_t mozilla_t:process noatsecure;
Thanks for the pointers. I will take a look and let you know if I have
any further questions.
Regards,
Aaron
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SELinux policy regarding LD_LIBRARY_PATH
2011-08-04 12:14 SELinux policy regarding LD_LIBRARY_PATH Aaron Sowry
2011-08-04 12:50 ` Sven Vermeulen
@ 2011-08-04 13:09 ` Stephen Smalley
2011-08-04 13:39 ` Aaron Sowry
1 sibling, 1 reply; 6+ messages in thread
From: Stephen Smalley @ 2011-08-04 13:09 UTC (permalink / raw)
To: Aaron Sowry; +Cc: selinux
On Thu, 2011-08-04 at 14:14 +0200, Aaron Sowry wrote:
> Hi,
>
> It appears that with SELinux enabled, the LD_LIBRARY_PATH environment
> variable is not inherited by user processes forked by a root process.
> This is on RHEL6.
>
> What is the general SELinux policy regarding LD_LIBRARY_PATH? Is there
> any way to change this behaviour? I couldn't find any documentation
> regarding this.
I see that Sven has answered your question, but wanted to clarify one
point: this behavior happens on execve, not on fork, and only if the
process security context changes (whether an automatic transition or
explicit request by the caller via setexeccon prior to execve).
However, the behavior you are seeing might not be related to SELinux, as
Linux also enables AT_SECURE if the uid or gid changes across execve (to
be precise, if the effective identity is not equal to the real identity
after the credential change, as this was the legacy logic from libc).
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SELinux policy regarding LD_LIBRARY_PATH
2011-08-04 13:09 ` Stephen Smalley
@ 2011-08-04 13:39 ` Aaron Sowry
2011-08-04 13:47 ` Stephen Smalley
0 siblings, 1 reply; 6+ messages in thread
From: Aaron Sowry @ 2011-08-04 13:39 UTC (permalink / raw)
To: Stephen Smalley; +Cc: selinux
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
> However, the behavior you are seeing might not be related to SELinux, as
> Linux also enables AT_SECURE if the uid or gid changes across execve (to
> be precise, if the effective identity is not equal to the real identity
> after the credential change, as this was the legacy logic from libc).
So if I understand correctly, SELinux expands on AT_SECURE to sanitize
environment variables across context changes instead of just
setgid/setuid. Makes sense; you live and learn.
In this case I believe it was SELinux performing the sanitization as
disabling it solved the problem, but this is helpful to know.
/Aaron
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: SELinux policy regarding LD_LIBRARY_PATH
2011-08-04 13:39 ` Aaron Sowry
@ 2011-08-04 13:47 ` Stephen Smalley
0 siblings, 0 replies; 6+ messages in thread
From: Stephen Smalley @ 2011-08-04 13:47 UTC (permalink / raw)
To: Aaron Sowry; +Cc: selinux
On Thu, 2011-08-04 at 15:39 +0200, Aaron Sowry wrote:
> > However, the behavior you are seeing might not be related to SELinux, as
> > Linux also enables AT_SECURE if the uid or gid changes across execve (to
> > be precise, if the effective identity is not equal to the real identity
> > after the credential change, as this was the legacy logic from libc).
>
> So if I understand correctly, SELinux expands on AT_SECURE to sanitize
> environment variables across context changes instead of just
> setgid/setuid. Makes sense; you live and learn.
>
> In this case I believe it was SELinux performing the sanitization as
> disabling it solved the problem, but this is helpful to know.
Just to clarify, we introduced AT_SECURE for SELinux. Prior to SELinux,
userspace directly used AT_EUID/AT_UID and AT_EGID/AT_GID to decide
whether to sanitize the environment. When we wanted a similar mechanism
for SELinux, Roland McGrath suggested that we create an AT_SECURE flag
that could be set by the kernel whenever a security-relevant change has
taken place, and then rework userspace to use that flag when present.
Thus we have a more general mechanism today that can be used for
setuid/setgid, capability changes, SELinux security context transitions,
or any other security module.
--
Stephen Smalley
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2011-08-04 13:47 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-08-04 12:14 SELinux policy regarding LD_LIBRARY_PATH Aaron Sowry
2011-08-04 12:50 ` Sven Vermeulen
2011-08-04 13:06 ` Aaron Sowry
2011-08-04 13:09 ` Stephen Smalley
2011-08-04 13:39 ` Aaron Sowry
2011-08-04 13:47 ` Stephen Smalley
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.