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.
Why eactly does the list of domains need to be protected by the list
of uids?
--
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat