[Freeipa-devel] [PATCH] 1106 IPA REST smart proxy

[Simo Sorce]

On Mon, 2014-02-17 at 11:27 -0500, Dmitri Pal wrote:
> On 02/17/2014 07:53 AM, Simo Sorce wrote:
> > On Sun, 2014-02-16 at 21:54 -0500, Dmitri Pal wrote:
> >> On 02/16/2014 06:49 AM, Simo Sorce wrote:
> >>> On Fri, 2014-02-14 at 16:52 -0500, Rob Crittenden wrote:
> >>>> - listens on port 8090, only on localhost
> >>>> - is unauthenticated
> >>> Sorry to come late, but I am really at unease with this point.
> >>>
> >>> Can we do at least some form of simple authentication ? Even if it is a
> >>> shared secret in a file accessible by both foreman and smartproxy ?
> >>>
> >>> Simo.
> >>>
> >> Simo, it is such by design.
> > The design is that foreman can connect to the local proxy in a simple
> > way. We can do it w/o exposing completely open interfaces to the local
> > host.
> >
> >> The interface is local only and smart proxy explicitly checks that is it
> >> called locally byt a local process.
> > If it were using a unix socket that can be protected by permissions I
> > would have no qualms, but afaik this is listening on a network port on
> > localhost. It means *any* process can connect, they are all local.
> >
> >> The daemon by itself will then do a remote authenticate against IPA.
> >> We trust Foreman machine to make the host changes and allow it to make
> >> only these changes using access control rules on the server.
> >> I do not think we need or can change anything here.
> >> Any kind of authentication would significantly complicate integration
> >> with Foreman and I frankly do not see a value in another level of
> >> authentication.
> >> I.e. how certs or key in the file makes it more secure?
> > By allowing only the Foreman process to successfully connect.
> >
> >> I would rather suggest some SELInux policies that would open the REST api port to only
> >> specific labels.
> > Sure SELinux should certainly be used, but not everybody runs SELinux.
> 
> Right, but do we care? If you disable SELInux you open it to the whole 
> host this is your choice.

SELinux is always optional, it is an add-on layer. It is ok to recommend
it, but not to require it for basic protection. Sometimes we also need
to put it in permissive to work around bugs, so it cannot be the only
protection available.

> > A shared file with a secret that only foreman and the proxy can access
> > is very simple, it can even be generated on the fly at stratup, w/o
> > requiring any special manual setup.
> 
> 
> Then you need to deal with permissions and labeling of this file and 
> make sure that only these two can access again based on SELinux labels.
> And if you turn SELinux then other applications would be able to access 
> if they can su to that user.

No, this is an incorrect characterization.

Although it is true we will also add SELinux protections on a file, the
first thing that matters in files are permissions. Of course the file
will need to be readable by the user nuder which foreman runs and the
user under which the smartproxy runs.
But that is doen by making the file readable by only those 2 users,
either by adding an ACL or by putting the 2 users in a group and making
the file readable only by the group. In either case SELinux is not the
gate, it is an added protection.

Aside: If an application can "su to a user" it is game over, but that is
not the case in normal circumstances so not something we need to worry
about.

> IMO we should explore local socket path if possible first and make sure 
> that only foreman can connect, then rely on SELInux and only if these 
> options get exhausted start adding complexity to do the authentication 
> of the API using shared secrets or certs. Keep in mind that the 
> authentication was explicitly out of scope for the first round. I am 
> generally no against it as next step. I am just against it being jammed 
> in now.

not authenticating is ok at a prototype phase. I am bringing it up now
because we are clearly getting out of prototype and we want to push
upstream. I cannot sanction something for upstream that works
unauthenticated when exposing a port over the network, even if we listen
just to 127.0.0.1. Again SELinux is add-on, cannot be the only barrier,
for the reasons stated above.

Big +1 to using a socket if possible. [still has the same problems as a
file (permissions and labels need to be right) but that is also why it
can be instead of adding shared secret ot similar, it has protections a
network port can't give].

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York