Util-Linux package development
 help / color / mirror / Atom feed
From: "L. Walsh" <lkml@tlinx.org>
To: Ray Strode <halfline@gmail.com>
Cc: util-linux@vger.kernel.org, Karel Zak <kzak@redhat.com>,
	Lennart Poettering <lennart@poettering.net>
Subject: Re: [PATCH] login-utils: import environment from user manager on systemd systems
Date: Thu, 27 Oct 2016 14:53:26 -0700	[thread overview]
Message-ID: <58127756.7070409@tlinx.org> (raw)
In-Reply-To: <CAA_UwzKqEsXDOrayqMHsLOXzB72YfNMyuWa4b0ODcbrqnGgDmw@mail.gmail.com>

Ray Strode wrote:
> Hi,
>   
>>    Isn't pam_env supposed to allow setting vars in setting up
>> a user's first login session?
>>     
> It can, but it has a few problems
>
> 1) the file format is kind of weird
>   
---
    People looking at systemd's config files have said similar.

> 2) not all distros set user_readenv=1 so users cant set the
> environment variables they want
>   
----
    pam_env wasn't designed for reading user-set environment variables.
Can users modify systemd config files at will?  Can't users put their
envvars in their profiles? 

> 3) pam_env doesn't provide a facility for 3rd party applications to
> adjust the environment
>   
---
    I wasn't aware systemd could read users' profiles.  I've seen
many 3rd party apps add their needed env vars to the system "profile.d"
directory (for system wide changes) and some to a user's shell if they
were user-specific changes.
> 4) PAM modules run in the context of a user but as root.
----
    Most login related and system security processes do.  They are not
part of the kernel.  Systemd runs in a user-context as root, as well.
Are you saying that is insecure?

`   Pam_env is designed to be run before the user's first session has
been setup and not again.  Some environment variables are meant to have
the same lifetime as the login-(or audit) UID.  Just like TERM, any X
programs rely on DISPLAY and those things don't change unless a
new first-contact session is created when a user first accesses a
secure network from an outside location. 

> Having a
> bunch of independent plugins all running as root, and not necessarily
> integrating with each other is a recipe for security problems,
> especially if you throw environment variables into the mix.
>   
----
    True.  The pam modules have been vetted for about 10+ years and have 
good
security record, yet you seem quite willing to jump to a new solution
without such a track record. 
> (if pam_env is erroneously in the session stack before a pam_exec
> call, the user could easily get root access).
>   
If an administrator  misconfigures ANY system security and 
authentication modules a user could gain root access.  Pam_env was 
designed for a
first-contact to the system, as that's the only time 'REMOTEHOST' is set 
(presuming the user came from another system).  Does systemd set REMOTEHOST
and allow for a users DISPLAY variable to be defaulted to a dependent 
setting?
> This topic was discussed a bit in the cited systemd pull request, I think.
>   
----
    how is that relevant to a util-linux list?
-l

  reply	other threads:[~2016-10-27 21:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-25 20:34 [PATCH] login-utils: import environment from user manager on systemd systems Ray Strode
2016-10-25 21:06 ` Linda Walsh
2016-10-26 19:38   ` Ray Strode
2016-10-27 21:53     ` L. Walsh [this message]
2016-10-28 15:06       ` Ray Strode
2016-10-28  3:02 ` L. Walsh
2016-10-28 15:14   ` Ray Strode
2016-12-07 19:45 ` Ray Strode
2016-12-07 20:04   ` Ruediger Meier
2016-12-08 11:24     ` Karel Zak
2016-12-08 15:00       ` Ray Strode
2016-12-08 18:39         ` Fwd: " Ray Strode

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58127756.7070409@tlinx.org \
    --to=lkml@tlinx.org \
    --cc=halfline@gmail.com \
    --cc=kzak@redhat.com \
    --cc=lennart@poettering.net \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox