Re: [foxboro] Foxboro I/A OPC - Security
- From: Corey R Clingo <corey.clingo@xxxxxxxx>
- To: foxboro@xxxxxxxxxxxxx
- Date: Mon, 22 May 2006 07:05:08 -0400
Normally these points are valid. But some peculiarities of I/A make this
more difficult than it sounds.
"/opt/disp,/opt/menus,/opt/overlays contains all your display files.
If you now create a small copy/move/delete script that only allows to work
under these directories, you create the certainty that system files cannot
be modified or removed."
Unless you write a small C wrapper around FoxDraw/Display Builder/Display
Configurator, or use sudo or something like it, to drop root privileges
before running FD/DB/DC, you really can't do this. DM (and FV too, I
believe) runs as root on the local system, and any child process spawned
(like configurators of various kinds) also run as root.
"PS: Make sure that the regular user cannot modify
this type of scripts !!"
Also easier said than done. Even if you use the privilege-dropping
wrapper I describe above, a savvy graphics builder can run any manner of
script or program from within DM or FV using DM commands. These also
execute as root on the local WP/AW (they are again child processes of the
run-as-root DM/FV).
I've ruminated endlessly about how to make I/A more secure (even outside
of work hours - egad!). I've been somewhat successful in the remote
access case (though I had to use some Cassandra tools, and I don't know
what vulnerabilities the DM/FV program itself contains), but in the local
case, the best answer I can come up with is good and frequent backups.
DCSs were not designed with security in mind, and since it probably would
take a major code rewrite to put real security into these systems, the DCS
vendors are at a minimum waiting until major new releases--where they have
to do major rewrites anyway--to try.
To answer Andreas's original question, remote DMs run non-root, but trying
to get configurators to do so is a hassle. There is a document on the CSC
web site I believe describing the changes one needs to make to a Solaris
box to get the normal suite of configurators to run this way, but it
looked like too much to do once, much less repeatedly after upgrades.
Corey Clingo
BASF Corp.
"Lieven Taleman" <lieven.taleman@xxxxxxxxx>
Sent by: foxboro-bounce@xxxxxxxxxxxxx
05/20/2006 09:36 AM
Please respond to
foxboro@xxxxxxxxxxxxx
To
<foxboro@xxxxxxxxxxxxx>
cc
Subject
Re: [foxboro] Foxboro I/A OPC - Security
Hi Andreas,
One of the main security issues is the ability to determine which action a
certain user can take based on his profile.
If we let them all work under the root account in an open shell there is a
high risk that someone can accidently execute a command that destabilizes
the system.
A nice and easy feature is the use of the sudo program. With this, you can
define which commands can be executed and by who.
A Foxboro I/A system can be splitted up in directory paths with different
tasks. One of the main tasks is file management
E.g. /opt/disp,/opt/menus,/opt/overlays contains all your display files.
If you now create a small copy/move/delete script that only allows to work
under these directories, you create the certainty that system files cannot
be modified or removed. (PS: Make sure that the regular user cannot modify
this type of scripts !!. A better solution is using a graphical file
explorer that limits the accessible directories.
Greetings,
Lieven Taleman
B.V.B.A Talsoft - Belgium
lieven.taleman@xxxxxxxxxx
-----Oorspronkelijk bericht-----
Van: foxboro-bounce@xxxxxxxxxxxxx
[mailto:foxboro-bounce@xxxxxxxxxxxxx]Namens Johnson, Alex P (IPS)
Verzonden: vrijdag 19 mei 2006 21:38
Aan: foxboro@xxxxxxxxxxxxx
Onderwerp: Re: [foxboro] Foxboro I/A OPC - Security
In general, anything that accesses the OM needs root permissions. You can
grant any program root permissions by using the chmod command:
chmod +4000 <pgmName>
The application could then be run by someone other than root as if root
had
run it.
Other issues running as a different user tend to boil down to directory
access permissions.
Hope this helps.
Regards,
Alex Johnson
Invensys Systems, Inc.
10900 Equity Drive
Houston, TX 77041
713.329.8472 (voice)
713.329.1700 (fax)
713.329.1600 (switchboard)
alex.johnson@xxxxxxxxxxxxxxxx
-----Original Message-----
From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
On
Behalf Of Weiss, Andreas
Sent: Saturday, March 11, 2006 7:36 AM
To: foxboro@xxxxxxxxxxxxx
Subject: Re: [foxboro] Foxboro I/A OPC - Security
> A software guy loves to work under full access (say root)=20
> because than he
> does not has to worry about "permission denied" issues.
Hi,
which I/A series applications on a Solaris Box can run under another
account than root?
Has anyone experience in this field for example building display under a
normal user account (that is a non root account)?
Greetings,
Andreas
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
foxboro mailing list: http://www.freelists.org/list/foxboro
to subscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe: mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
- Follow-Ups:
- Re: [foxboro] Foxboro I/A OPC - Security
- From: brad . s . wilson
- References:
- Re: [foxboro] Foxboro I/A OPC - Security
- From: Lieven Taleman
Other related posts:
- » Re: [foxboro] Foxboro I/A OPC - Security
- » Re: [foxboro] Foxboro I/A OPC - Security
- » Re: [foxboro] Foxboro I/A OPC - Security
- » Re: [foxboro] Foxboro I/A OPC - Security
- » Re: [foxboro] Foxboro I/A OPC - Security
- » Re: [foxboro] Foxboro I/A OPC - Security
- » Re: [foxboro] Foxboro I/A OPC - Security
- » Re: [foxboro] Foxboro I/A OPC - Security
- Re: [foxboro] Foxboro I/A OPC - Security
- From: brad . s . wilson
- Re: [foxboro] Foxboro I/A OPC - Security
- From: Lieven Taleman