Tango Access Control security

# 7 years ago
philippeg	Hello tangoers, we made some tests with TAC, and I would like to understand a specific point: is there any way to block the possibility to bypass TAC by an environment variable? In the case of a computer which can be accessed by anyone, one would like to avoid anyone who can access to a terminal to have write access to any device. Is there any way to avoid this? Thank you. - Philippe

# 7 years ago
Pascal	Hi Philippe You can bypass the TAC for a java program (Astor for instance or TAC manager) if you run it with the environment variable: SUPER_TANGO=true

# 7 years ago
philippeg	Thank you Pascal. In fact, that is precisely the point I want to manage: how to avoid this capacity of anyone with an access to a terminal to bypass TAC? - Philippe

# 7 years ago
Reynald	philippeg Thank you Pascal. In fact, that is precisely the point I want to manage: how to avoid this capacity of anyone with an access to a terminal to bypass TAC? As it is now, you can't, unless you recompile the Tango kernel code and use only Tango libraries recompiled with this code. TAC was designed to prevent some users to execute commands/write attributes they are not supposed to execute/write. In the current design, it is the responsibility of everyone to use the proper environment… It is the responsibility of the user to not bypass TAC (Most of the users don't know about this possibility. Even though this "feature" is documented, it is usually not known by the users). This might change now with topics like this on the forum… TAC was never designed against malicious user behaviour. Of course, we can discuss on a way to improve the system for the future versions and make it less easy to bypass TAC. In any case, it is always useful to be able to bypass it if you don't want to get stuck in the case you accidentally blocked yourself or if you forgot your TAC admin password. kind regards, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 7 years ago

Reynald

philippeg
Thank you Pascal.
In fact, that is precisely the point I want to manage: how to avoid this capacity of anyone with an access to a terminal to bypass TAC?

As it is now, you can't, unless you recompile the Tango kernel code and use only Tango libraries recompiled with this code.
TAC was designed to prevent some users to execute commands/write attributes they are not supposed to execute/write.
In the current design, it is the responsibility of everyone to use the proper environment… It is the responsibility of the user to not bypass TAC (Most of the users don't know about this possibility. Even though this "feature" is documented, it is usually not known by the users). This might change now with topics like this on the forum… smile

TAC was never designed against malicious user behaviour.
Of course, we can discuss on a way to improve the system for the future versions and make it less easy to bypass TAC.
In any case, it is always useful to be able to bypass it if you don't want to get stuck in the case you accidentally blocked yourself or if you forgot your TAC admin password.

kind regards,
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 7 years ago
philippeg	Thank you Reynald, it answers my question. I understand that TAC is used in a collaborative context but I need others tools to control write access to devices on a computer which possibly give access to unauthorized users. - Philippe

# 7 years ago
philippeg	After thinking this, I wonder if a walkthrough could be to let the server define the name of the environment variable. It would allow anyone to continue to use the same environment variable by default but it which could/should be renamed. Does this seems realistic? - Philippe

# 7 years ago
Reynald	philippeg I misunderstood as Dusan. Tango kernel book mentions environment variable to set at 3 locations : in TANGO kernel book (7.14.2 page 190 and A.12.3.4 page 221) and TAC project page (http://www.tango-controls.org/community/projects/tango-access-control-tac/). However, it seems not very clear it has to be set on the server where runs TAC DS, even if it seems clear now you mention it. To clarify this point, perhaps a line can be added like "To launch [or run] Tango Access Control DS, SUPER_TANGO environment variable has to be set to true". Sounds reasonable to me. philippeg Another question: do we should set this variable when launching TAC DS or during the whole time this DS is launched? This environment variable should be set only in the environment of the TAC DS. So usually what is done is that TAC DS is started by a script which will set the environment variable before starting the TAC DS. In the tango distribution, by default, this script is /usr/local/bin/tango_wca (Tango with Control Access). It does already the job for you. So you can start The Tango Database, Tango Database server and Tango Access Control server using the following command: `tango_wca start` I just tested it on an Ubuntu 16.04 and this script was reporting errors on this platform… As a quick and dirty fix, you can replace the line 168: `findproc TangoAccessControl` with `findproc TangoAccessC` and line 186: `killproc TangoAccessControl` with `killproc TangoAccessC` philippeg What is the normal behavior if the DS has been configurated to give write access to anyone to any device from everywhere but TAC DS is stopped? In this case, users will have read-only access (if they didn't define the super environment variable). The clients which were already connected to some TANGO devices will still be able to write attributes, send commands to these TANGO devices (if they need to reconnect at some point, they will probably switch to Read-Only access mode). philippeg After thinking this, I wonder if a walkthrough could be to let the server define the name of the environment variable. It would allow anyone to continue to use the same environment variable by default but it which could/should be renamed. Does this seems realistic? How/where would you specify this environment variable name? We can imagine this environment variable name to be a configuration option of the Tango Source distribution for instance… But be careful if you are using several versions of the Tango libraries on your control system. You will have to keep track of the environment variable names configured by each library version and the versions from today and before will still expect SUPER_TANGO environment variable. I think there are many ways to change the current situation… I guess this will trigger interesting exchanges during the next Tango meeting. Kind regards, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 7 years ago

Reynald

philippeg
I misunderstood as Dusan.
Tango kernel book mentions environment variable to set at 3 locations : in TANGO kernel book (7.14.2 page 190 and A.12.3.4 page 221) and TAC project page (http://www.tango-controls.org/community/projects/tango-access-control-tac/). However, it seems not very clear it has to be set on the server where runs TAC DS, even if it seems clear now you mention it.
To clarify this point, perhaps a line can be added like "To launch [or run] Tango Access Control DS, SUPER_TANGO environment variable has to be set to true".

Sounds reasonable to me.

philippeg
Another question: do we should set this variable when launching TAC DS or during the whole time this DS is launched?

This environment variable should be set only in the environment of the TAC DS. So usually what is done is that TAC DS is started by a script which will set the environment variable before starting the TAC DS.
In the tango distribution, by default, this script is /usr/local/bin/tango_wca (Tango with Control Access). It does already the job for you.
So you can start The Tango Database, Tango Database server and Tango Access Control server using the following command:

tango_wca start

I just tested it on an Ubuntu 16.04 and this script was reporting errors on this platform…
As a quick and dirty fix, you can replace the line 168:

findproc TangoAccessControl

with

findproc TangoAccessC

and line 186:

killproc TangoAccessControl

with

killproc TangoAccessC

philippeg
What is the normal behavior if the DS has been configurated to give write access to anyone to any device from everywhere but TAC DS is stopped?

In this case, users will have read-only access (if they didn't define the super environment variable). The clients which were already connected to some TANGO devices will still be able to write attributes, send commands to these TANGO devices (if they need to reconnect at some point, they will probably switch to Read-Only access mode).

philippeg
After thinking this, I wonder if a walkthrough could be to let the server define the name of the environment variable.
It would allow anyone to continue to use the same environment variable by default but it which could/should be renamed.
Does this seems realistic?

How/where would you specify this environment variable name?
We can imagine this environment variable name to be a configuration option of the Tango Source distribution for instance…
But be careful if you are using several versions of the Tango libraries on your control system. You will have to keep track of the environment variable names configured by each library version and the versions from today and before will still expect SUPER_TANGO environment variable.
I think there are many ways to change the current situation… I guess this will trigger interesting exchanges during the next Tango meeting.

Kind regards,
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 7 years ago
philippeg	Here is a report of what I understand on use of TAC : 1. connect as root and to export the environment variable (into root environment) and start the TAC instance : `sudo su export ENV_VARIABLE=true /usr/lib/tango/TangoAccessControl 1` 2. connect to astor and open Manager Panel of "Access Control" (under "Tango Database") 3. on any client computer, if one need to access to DS without rights control access, one can define environment variable to by-pass it. Feel free to complete/correct, and thanks to ESRF team, especially Pascal and Reynald. - Philippe

# 7 years ago

philippeg

Here is a report of what I understand on use of TAC :

1. connect as root and to export the environment variable (into root environment) and start the TAC instance :


sudo su
export ENV_VARIABLE=true
/usr/lib/tango/TangoAccessControl 1

2. connect to astor and open Manager Panel of "Access Control" (under "Tango Database")

3. on any client computer, if one need to access to DS without rights control access, one can define environment variable to by-pass it.

Feel free to complete/correct, and thanks to ESRF team, especially Pascal and Reynald.

- Philippe