Re: [Cs-studio-core] CSS authorization and authentication idea

[Carcassi, G. <car...@bn...>]

>If the Eclipse preferences, GUI or not,
>allow me to simply say "use the JAAS 'file' setup",
>I can define whatever user and password I want.
Right, which does not sound too good... Let's see.

For services, this is not a problem. You have deployed on a server, which you need to protect. If someone is able to change the configuration, it means that has already breached the server. And it's too late at that point.

The service should also never "trust" the client authentication unless there is a token. So, the fact that you have authenticated as "root" to CSS, does not mean anything: either you have a "root" token which you can pass, which means you broken Kerberos which means CSS is the least of your problems, or you have to re-authenticate with the server, and you broke nothing. This works for services, databases, ... That is: you authenticated locally to CSS, but you haven't authenticated to ChannelFinder, Olog, ... So you can't do mush anyway.

The only case that remains is that of the security on the client: you use the CSS authentication to determine whether you should do or not do something. But that implies that, since CSS is passing the authentication anywhere, whatever you are doing could be done without authentication. So, CSS can't really enforce anything anyway... If the user action triggered a CSS action that required no authentication, then it's a "child-proofing" protection anyway. If the user action triggered a CSS action that did require authentication and CSS is using some global authentication settings, this is really bad because it means that the user could get that information anyway (CSS executes in user space) 

>Are we looking for Channel Access - like security, child-proofing?
>Or evil hacker proofing?
Sooooo.... since CSS client executes in user space anyway, whatever you have there is a "convenience". It can be bypassed anyway. A token system, though, it's a convenience that other services can trust. So, it actually buy you something.

On the server, it should be fine (as long as there isn't a backdoor to go and modify that file...)

Gabriele


-----Original Message-----
From: Kasemir, Kay [mailto:kas...@or...] 
Sent: Thursday, March 21, 2013 12:38 PM
To: Carcassi, Gabriele; cs-studio-core
Subject: Re: CSS authorization and authentication idea

One concern with the external script approach also applies to using Eclipse preferences in general for this.
If the Eclipse preferences allow me to define that script, I can easily point it to my own script and gain any access I want.


Same with authorization. This is a standard JAAS configuration:

file
{
 com.sun.jmx.remote.security.FileLoginModule required  passwordFile="/home/fred/mypasswords.conf";
};


and in mypasswords.conf I then put:

root=i_am_root

If the Eclipse preferences, GUI or not, allow me to simply say "use the JAAS 'file' setup", I can define whatever user and password I want.

Is that a problem?
Or is it OK?
Are we looking for Channel Access - like security, child-proofing? Or evil hacker proofing?

-Kay



On 3/21/13 12:20 , "Carcassi, Gabriele" <car...@bn...> wrote:
>>>id --groups --names [username]
>>No, for SNS we really need to go to LDAP.
>Yeah, I guess I was speaking in terms of "default" or "use case that 
>needs to be supported", not as "it should be good for everybody". You 
>may want to keep a separate file for the AuthN, and not use unix groups.
>
>For AccelUtils (ChannelFinder and Olog services) we call out to an 
>external script, that returns a set of strings which are then used for 
>AuthN inside the service. The script, on Linux, defaults to id, but can 
>be overridden. The idea is that, for a sysadmin, is easier to give you 
>a script that returns the right info than to create a Java class and 
>stick it in Glassfish. So, if you really need to get the groups from 
>LDAP, you can ask the sysadmin for the script (or you can do it using 
>the commandline tools that are already there).
>
>I don't know if you agree, but I think this cleanly separates. We can 
>clean up that idea if it needs to, put it in a common library, and then 
>we would align CSS and the other services. I'd _really_ like that this 
>is solved in the same way, whatever it may be...
>
>Gabriele