On Mon, Sep 22, 2014 at 02:03:51PM +0200, Jan Pazdziora wrote:
On Fri, Sep 19, 2014 at 08:26:48PM +0200, Jakub Hrozek wrote:
>
> === Overview of the solution ===
> On the PAM client side, the PAM module should receive a new option that
> specifies the SSSD domains to authenticate against. However, the SSSD
> daemon can't fully trust all PAM services. We can't rely on the PAM service
> fields either, as the data the PAM client sends to the PAM application can
> be faked by the client, especially by users who posses shell access or can
> start custom applications. Instead, there needs to be a list of users who
> we trust. Typically, this would be a list of users who run the PAM aware
> applications we wish to restrict (such as `vsftpd` or `openvpn`). This list
> would default to `root` only.
>
> These trusted users would be allowed to authenticate against any domain
> and would also be able to restrict the domains further using a new pam_sss
> option. For the untrusted users, we need to keep a list of domains allowed
> to authenticate against, too. Since by default there are no restrictions
> on the allowed domains, this list would default to "all domains are
allowed".
What would be the recommended workflow for services that create new
PAM services on the fly. Think of hosting multitude of web services
(Apaches) running each in different uid. When setting up that web
service, PAM server might get configured for it, restricting the list
of domains this PAM service is allowed/supposed to use. For this to
work, sssd.conf would need to be amended each time and sssd restarted,
adding new uid of the new Apache setup to the list of
pam_trusted_users.
Would adding each of the users to a certain group and amending the
configuration so that also a trusted GID can be specified help?
Why eactly does the list of domains need to be protected by the list
of uids?
Apparently the rest of the PAM data can be faked by the client.
See:
https://lists.fedorahosted.org/pipermail/sssd-devel/2014-July/020895.html
and:
https://lists.fedorahosted.org/pipermail/sssd-devel/2014-July/020897.html
and:
https://lists.fedorahosted.org/pipermail/sssd-devel/2014-July/020907.html