Code Signing, Embedded languages, and
Security
Versions of HPCC Systems® platform prior to
6.0.0 have always allowed some control over which operations were permitted
in ECL code. This was done, primarily, as a way to ensure that operations
like PIPE or embedded C++ could not be used to circumvent access controls on
files by reading them directly from the operating system.
Version 6.0.0 (and above) has two features to provide more flexibility
over the control of these operations.
We now limit which SERVICE functions are called at compile time
using the FOLD attribute. FOLD on a service or function definition
within it requires additional rights. Typically, for security reasons ,
FOLD should only be enabled in signed modules.
You can configure the access rights (which control the ability to
use PIPE, embed C++, or declare a SERVICE as FOLDable) to be dependent
on the code being signed. This means that we can provide signed code in
the ECL Standard Library that makes use of these features, without
opening them up for anyone to call anything.
ECLCC Configuration Settings
In Configuration Manager, the ECLCC Server component has a tab named
Options. This tab allows you to enter
name value pairs for permissions to execute various types of embedded code
or plug-ins.
Name
-allow
Allow the option specified.
-deny
Deny the option specified.
-allowsigned
Allow the option specified if the code has been signed
and the key is present.
Cluster
Specify the cluster for which this rule applies.
Value
cpp
Allow/Deny C++ and other embedded languages. For languages
other than C++ and Cassandra, an optional plug-in must also be
installed
pipe
Allow/Deny using external applications using the PIPE
command.
foldextern
Allow/Deny SERVICE functions using FOLD
extern
Allow/Deny an external function
Code Signing
Code signing is similar to the way that emails can be signed to
prove that they are from who they say they are and they have not been
tampered with, using the standard gpg package.
A file that has been signed will have an attached signature
containing a cryptographic hash of the file contents with the signer’s
private key. Anyone in possession of the signer’s public key can then
verify that the signature is valid and that the content is
unchanged.
We have signed the SERVICE definitions provided by the ECL standard
plug-ins and included the public key in the HPCC platform installation.
Code that tries to use service definitions that are signed will continue
to work as before but, code that tries to call arbitrary library functions
using user-supplied SERVICE definitions will give compile errors, if
signing has not been used.
System administrators can install additional keys on the ECLCC
Server machine, so if you want to use your own service definitions, they
can be signed using a key that has been installed in this way:
gpg --output <signed-ecl> --default-key <key-id> --clearsign <ecl-file-to-sign>
Using this method, a trusted person can sign code to indicate that
it is acceptable for untrusted people to use, without allowing the
untrusted people to execute arbitrary code.