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

[Dmitri Pal]

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.

> 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.

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.

>
> Simo.
>


-- 
Thank you,
Dmitri Pal

Sr. Engineering Manager for IdM portfolio
Red Hat Inc.


-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/