Re: ejabberd, pam, and setuid root

[Stephen Gallagher]

On 09/01/2016 01:31 AM, Randy Barlow wrote:
>  Hello my fellow Fedora friends!
>  
>  It's 01:00 in my local time and perhaps I should be resting instead of
>  trying to figure out chicken-and-egg problems at such a time, but my
>  tired mind is on the fence about the solution to one of my tickets and
>  I would love the input of others:
>  
>  https://bugzilla.redhat.com/show_bug.cgi?id=1371984
>  
>  Let's just say that daemon package A creates user/group A and depends
>  on library B. One of library B's binaries needs to be installed setuid
>  root because it is for PAM authentication, but I'd rather install the
>  binary 4750 or 4700 than 4755. To do this, I can only think of four
>  solutions:
>  
>  0) library B installs with 4700, and daemon package A sets a facl on
>  the binary to allow user A to execute it. This seems pretty cool, but
>  also weird to me since it seems odd for a package to modify a file from
>  another package. Additionally, it seems like future updates to library
>  B might disrupt the facls that were set by daemon package A until the
>  next time it was installed/updated. That sounds right anyway, and if it
>  is right I think this option is a no-go. Simple tests with the install
>  utility on my fs did obliterate facls when new files were installed
>  over existing files. A crazy workaround for this problem might be to
>  detect whether the facls are present before the upgrade with %pre, and
>  restore them in %post.
>  
>  1) library B creates group A (even though the library isn't necessarily
>  only for daemon package A who is the only package to create this
>  user/group at this time), and then sets its binary to 4750, owned by
>  group A. This one is a little easier than the first option, since I'd
>  only have to make an update to library B rather than both A and B. The
>  only thing is that it seems kind of weird for library B to be creating
>  a group called A, when library B is theoretically generally useful on
>  its own and theoretically could have other packages that pull it in in
>  the future. It would be weird for group A to exist if package A were
>  not installed I think. Fortunately, it wouldn't need to create user A
>  as well, only the group.
>  
>  2) We could leave the problem up to documentation, instructing users to
>  set the facls or group ownership. However, this will suffer from the
>  same update problem that the first solution suffers from, and the user
>  will need to reset the facls whenever this package were updated.
>  
>  3) We could rely on an SELinux policy to ensure that only ejabberd can
>  execute this binary. I don't like this for two reasons: users who
>  disable SELinux wouldn't have the fallback regular Unix permissions as
>  the second layer of defense. Secondly, unconfined users would still be
>  able to run the binary. If there were ever security issues found in the
>  binary itself, neither of these situations would be ideal.
>  
>  Option #1 seems to have the fewest technical concerns, so I lean in
>  that direction. Hopefully sleeping will get my mind to its peak
>  efficiency and I'll see some obvious solution in the morning, but I'd
>  love to hear what others think. Is there precedent for this problem? Do
>  you have any other options that I haven't thought of? Thanks for any
>  input you can offer!
>   
Does ejabberd in Fedora need to use local authentication in all cases (default
configuration), or is this something that is configured by the user after
installation?

If the latter, one thing you could do is avoid needing to give epam privileges
at all and have it use pam_sss.so instead of pam_unix.so and then set up SSSD
with the proxy provider like:


== sssd.conf ==

[sssd]
services = nss, pam
config_file_version = 2
domains = ejabberd


[nss]


[pam]


[domain/ejabberd]

id_provider = proxy
proxy_lib_name = files

auth_provider = proxy
proxy_pam_target = ejabberd


Then you configure /etc/pam.d/ejabberd to use pam_unix.so

SSSD is already a privileged process, so it will perform the authentication on
your behalf and forward the result back to epam.




In the future (hopefully F26...) we're going to be making SSSD processing of
local users a default for Fedora[1]. So when that happens, the manual SSSD
configuration will go away and you should be able to just always trust that
pam_sss.so will return proper information.


[1] https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider