This GET API is in charge to show the whitelist associated with the pod specified through the {pod id} placeholder.
PUT /v2/agents/{agent_id:UUID}/pods/{pod_id}/allowlist
This PUT API is in charge to substitute the whitelist associated with the pod specified through the {pod id} placeholder, with the new whitelist provided in the request body.
The Request JSON object will contain the new whitelist for the {pod id}
GET /v2/agents/{agent_id:UUID}/pods/{pod_id}/exclude
This GET API is in charge to show the exclude list associated with the pod speci-fied through the {pod id} placeholder.
PUT /v2/agents/{agent_id:UUID}/pods/{pod_id}/exclude
This PUT API is in charge to substitute the exclude list associated with the pod specified with the {pod id} placeholder, with the new exclude list provided in the request body.
• agent ip, that is the Keylime Agent IP address.
• ptype, that is the payload type. It can assume values 0 (FILE), 1 (KEY-FILE), or 2(CA DIR).
• file data, that is the payload. If the field ptype is equal to 0, then it is encrypted by the Keylime Tenant with a random bootstrap key. If the field ptype is equal to 1, then it is encrypted with the bootstrap key specified within keyfile data.
• keyfile data, this field contains a bootstrap key which is used when the field ptype is equal to 1.
• include dir data, this field is needed when the field ptype is equal to 2, and it contains a list of data to be sent in a zip to the Keylime Agent.
• include dir name, this field is needed when the field ptype is equal to 2, and it contains the names of file data specified in the include dir data.
• ca dir, this field is needed when the field ptype is equal to 2, and it contains the path of the directory on which the Keylime Tenant is running.
• ca dir pw, this field is needed when the field ptype is equal to 2, and it contains the CA password.
• tpm policy, that is used to specify the PCRs that must be included in each TPM quote contained in the IR.
• vtpm policy, that is used as the tpm policy when virtual PCRs are involved.
• a list data, that is the whitelist of the host system.
• e list data, that is the exclude list of the host system.
• ima sign verification keys, that corresponds to the list of IMA public keys for signature verification.
• mb refstate, that is the policy associated with the measured boot.
• pods, that represents a JSON object for each pod to be registered in the Keylime Agent. The JSON object contains the a list data for the whitelist, and the e list data for the exclude list.
All the other APIs are not reported because they are internally invoking the ones exposed by the CLI.
Developer’s manual
B.1 IMA patch
This section provides the steps needed to create the IMA patch used in the proposed work. By way of information, the starting point has been implemented by the TORSEC research group of Polytechnic of Turin.
B.1.1 ima-cgpath template implementation
As explained in chapters 5 and 6, the ima-cgpath template has an additional field for the control group path that is unsupported by IMA, so the first thing to do is to move into the Linux kernel source code directory and open:
$ nano ./security/integrity/ima/ima_template.c
Then add to the array called supported fields the following content:
static const struct ima_template_field supported_fields[] = { ...
{.field_id = "cg-path", .field_init = ima_eventcg_path_init,
.field_show = ima_show_template_string}, };
where:
1. ”cg-path” represents the field identifier
2. ”ima eventcg path init” represents the function used to initialize the field value for the Measurement Events
3. ”ima show template string” represents the function used to write the field value in the Measurement Logs
Then in the same file define a new builtin template named ”ima-cgpath” with format string ”dep—cg-path—d-ng—n-ng”:
static struct ima_template_desc builtin_templates[] = { ...
{.name = "ima-cgpath", .fmt = "dep|cg-path|d-ng|n-ng"}, };
the ”dep” field represents the dependencies of the process that created the entry, and it has been defined by TORSEC research group of Polytechnic of Turin since also this parameter was not among those supported by IMA. The field ”cg-path” is the control group path (needed to establish the pod UID), while ”d-ng” and ”n-ng”
are respectively the file digest and the file path.
The next operations to do are to put the prototype of the function ima eventcg path init within the file ima template lib.h:
int ima_eventcg_path_init(struct ima_event_data *event_data, struct ima_field_data *field_data);
and to put its definition in the file ima template lib.c:
/*
* ima_eventcg_path_init - include the current task’s cgroup path as part of the
* template data
*/
int ima_eventcg_path_init(struct ima_event_data *event_data, struct ima_field_data *field_data) {
char *cgroup_path_str = NULL;
struct cgroup *cgroup = NULL;
int rc = 0;
cgroup_path_str = kmalloc(PATH_MAX, GFP_KERNEL);
if (!cgroup_path_str)
return -ENOMEM;
cgroup = task_cgroup(current, 1);
if (!cgroup)
goto out;
rc = cgroup_path(cgroup, cgroup_path_str, PATH_MAX);
if (!rc)
goto out;
rc = ima_write_template_field_data(cgroup_path_str,
strlen(cgroup_path_str), DATA_FMT_STRING, field_data);
kfree(cgroup_path_str);
return rc;
out:
return ima_write_template_field_data("-", 1, DATA_FMT_STRING, field_data);
}
The function ima eventcg path init uses three local variables: