| Message ID | 20230204050954.11583-3-greg@enjellic.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Paul Moore |
| Headers | show |
| Series | Implement Trusted Security Event Modeling. | expand |
On Fri, Feb 03, 2023 at 11:09:42PM -0600, Dr. Greg wrote: > An entry was added to the ABI testing documentation to document > the files in the TSEM management filesystem. > > The file documenting the kernel command-line parameters was > updated to document the tsem_mode command-line parameter. > > The primary TSEM documentation file was added to the LSM > administration guide and the file was linked to the index of LSM > documentation. > > Signed-off-by: Greg Wettstein <greg@enjellic.com> > --- > Documentation/ABI/testing/tsemfs | 576 ++++++++ Ah, here's the documentation, thanks. > Documentation/admin-guide/LSM/index.rst | 1 + > Documentation/admin-guide/LSM/tsem.rst | 1240 +++++++++++++++++ > .../admin-guide/kernel-parameters.txt | 5 + > 4 files changed, 1822 insertions(+) > create mode 100644 Documentation/ABI/testing/tsemfs > create mode 100644 Documentation/admin-guide/LSM/tsem.rst > > diff --git a/Documentation/ABI/testing/tsemfs b/Documentation/ABI/testing/tsemfs > new file mode 100644 > index 000000000000..3d326934624c > --- /dev/null > +++ b/Documentation/ABI/testing/tsemfs > @@ -0,0 +1,576 @@ > +What: /sys/fs/tsem > +Date: November 2022 It's not November 2022 anymore :( thanks, greg k-h
On Thu, Feb 09, 2023 at 12:47:22PM +0100, Greg KH wrote: > On Fri, Feb 03, 2023 at 11:09:42PM -0600, Dr. Greg wrote: > > An entry was added to the ABI testing documentation to document > > the files in the TSEM management filesystem. > > > > The file documenting the kernel command-line parameters was > > updated to document the tsem_mode command-line parameter. > > > > The primary TSEM documentation file was added to the LSM > > administration guide and the file was linked to the index of LSM > > documentation. > > > > Signed-off-by: Greg Wettstein <greg@enjellic.com> > > --- > > Documentation/ABI/testing/tsemfs | 576 ++++++++ > Ah, here's the documentation, thanks. Very good, hopefully it was found to be complete. I will respond to the control plane filesystem concerns in your comments in response to the patch that introduces the filesytem. > > diff --git a/Documentation/ABI/testing/tsemfs b/Documentation/ABI/testing/tsemfs > > new file mode 100644 > > index 000000000000..3d326934624c > > --- /dev/null > > +++ b/Documentation/ABI/testing/tsemfs > > @@ -0,0 +1,576 @@ > > +What: /sys/fs/tsem > > +Date: November 2022 > It's not November 2022 anymore :( I know, we will fix all of the 2022 dates in the second spin of the patchset. > thanks, > > greg k-h Have a good evening. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity
On Sat, Feb 4, 2023 at 12:33 AM Dr. Greg <greg@enjellic.com> wrote: > > An entry was added to the ABI testing documentation to document > the files in the TSEM management filesystem. > > The file documenting the kernel command-line parameters was > updated to document the tsem_mode command-line parameter. > > The primary TSEM documentation file was added to the LSM > administration guide and the file was linked to the index of LSM > documentation. > > Signed-off-by: Greg Wettstein <greg@enjellic.com> > --- > Documentation/ABI/testing/tsemfs | 576 ++++++++ > Documentation/admin-guide/LSM/index.rst | 1 + > Documentation/admin-guide/LSM/tsem.rst | 1240 +++++++++++++++++ > .../admin-guide/kernel-parameters.txt | 5 + > 4 files changed, 1822 insertions(+) > create mode 100644 Documentation/ABI/testing/tsemfs > create mode 100644 Documentation/admin-guide/LSM/tsem.rst One of the more important requirements for any new LSM is that it documents a clear, understandable, and reasonable security model along with an implementation that faithfully implements that model. Before I looked at your code I wanted to try and understand the TSEM security model and a few things jumped out at me rather quickly, I imagine there would be others as I start to look a bit closer but I wanted to send these questions/comments along now to get your take on them ... > diff --git a/Documentation/ABI/testing/tsemfs b/Documentation/ABI/testing/tsemfs > new file mode 100644 > index 000000000000..3d326934624c > --- /dev/null > +++ b/Documentation/ABI/testing/tsemfs > @@ -0,0 +1,576 @@ ... > +What: /sys/fs/tsem/aggregate > +Date: November 2022 > +Contact: Greg Wettstein <greg@enjellic.com> > +Description: > + The aggregate file contains the ASCII base 16 > + representation of the 256 bit hardware platform > + aggregate that TSEM is modeling under. The platform > + aggregate is the extension measurement of the Trusted > + Platform Module PCR registers 0 through 8. I'm guessing the above is a typo and you mean PCRs 0 through 7 (not 8)? If not, you need to provide an explanation somewhere as to what you are using PCR 8 for in TSEM and how it is extended, etc. > +What: /sys/fs/tsem/measurement > +Date: November 2022 > +Contact: Greg Wettstein <greg@enjellic.com> > +Description: > + The measurement file contains the ASCII base 16 > + hexadecimal representation of the 256 bit measurement > + value of the security model that the process is > + operating in. > + > + The measurement value is the classic linear extension > + measurement of the model. An updated measurement > + value is created by extending the current measurement > + value with the state coefficient computed for a > + security event. > + > + This measurement value represents a time dependent > + measurement of a model and is susceptible to > + deviations caused by scheduling differences between > + subsequent invocations of a workload. Given the very volatile nature of this value, what is it used for in userspace? My apologies if I missed it in the docs. > +What: /sys/fs/tsem/points > +Date: November 2022 > +Contact: Greg Wettstein <greg@enjellic.com> > +Description: > + The points file contains the ASCII base 16 > + representation of the 256 bit security state points of > + a security domain/model. The number of entries in > + this file represent the number of security events that > + are represented by the model. A similar questions to the tsem/measurement file. If I understand you correctly, this is basically a series of SHA256 digests without any additional annotations, and without any ordering guarantees, yes? What is it used for in userspace? > +What: /sys/fs/tsem/state > +Date: November 2022 > +Contact: Greg Wettstein <greg@enjellic.com> > +Description: > + The state file contains the ASCII base 16 > + representation of the 256 bit value of the functional > + state of a security domain/model. > + > + The state value is a time independent representation > + of the measurement of a model/domain, and unlike the > + measurement value, is a time independent > + representation of the security state of a workload. > + > + This value is designed to be a single value that can > + be attested to represent whether or not a workload has > + deviated from a defined security behavior. It might be nice to explain how this value is calculated here in this file to remove any time or ordering dependencies. Once again my apologies if I missed it in the rest of the docs. > +What: /sys/fs/tsem/trajectory > +Date: November 2022 > +Contact: Greg Wettstein <greg@enjellic.com> > +Description: > + The trajectory file contains a description of the > + security events that have occurred in a security > + domain/model. > + > + Each entry in this file represents a single security > + event and consists of brace {} delimited fields that > + describe the characteristics of a security event. > + Each field has key=value pairs that define > + characteristics of the field. > + > + Each line in a trajectory, or forensics, file will > + always have the event{} and COE{} fields. The event > + field describes the characteristics of a security > + event while the COE field describes the Context Of > + Execution that is executing the security event. I think it would be good to provide a concrete definition of CELL_DEFINITION field as other areas of the documentation make reference to it within the tsem/trajectory file documentation. We can somewhat infer it's format, fields, etc. but it's much better to be explicit about these things. > + The event{} field consists of the following > + characteristic definitions: I'm unclear as to the purpose of the event{} field as it is neither part of the COE or the CELL, is it here simply to make the event easier to read? Or am I misunderstanding things and the event{} field is part of the COE? > + process=COMM > + Where COMM is the ASCII representation > + of the name of the process executing > + the event. > + > + filename=PATH > + If the CELL definition for an event > + references a file the filename > + characteristic contains a definition > + of the path to the file. > + > + In the case where an event does not > + have a file the PATH value is set to a > + value of none. What happens in cases where multiple file paths are present in an event? Also, given this is visible to userspace, and multiple things can affect the path to a file (e.g. namespaces), how is the file path determined? > + type=EVENT_TYPE > + The value field for a type key is the > + name of the security event that is > + being modeled. The list of value > + EVENT_TYPE names is defined in the > + following source file: > + > + security/tsem/tsem.c > + > + If the security event is a generically > + modeled event the EVENT_TYPE will be > + generic_event. In this case the CELL > + characteristics for the event will be > + described by a generic_event{} field. > + > + task_id=TASK_ID > + The value of the task_id key will the > + ASCII base 16 representation of the > + model identity of the task that is > + executing the security event. > + > + The following documentation file: > + > + Documentation/admin-guide/LSM/TSEM.rst > + > + Describes how the TASK_ID value is > + generated. > + > + The COE{} field consists of the following > + characteristic definitions: > + > + uid=NN > + The ASCII base 10 representation of > + the numeric value of the discretionary > + user id of the process that is > + executing the security event. Given the ability to map UID/GID values in the kernel, what will be used as the basis for the COE? What happens when the basis used in the kernel's COE generation does not match the basis used by the external modeler? > + euid=NN > + The ASCII base 10 representation of > + the numeric value of the effective > + discretionary user id of the process > + that is executing the security event. > + > + euid=NN > + The ASCII base 10 representation of > + the numeric value of the effective > + discretionary user id of the process > + that is executing the security event. > + > + suid=NN > + The ASCII base 10 representation of > + the numeric value of the saved user id > + of the process that is executing the > + security event. > + > + gid=NN > + The ASCII base 10 representation of > + the numeric value of the discretionary > + group id of the process that is > + executing the security event. > + > + egid=NN > + The ASCII base 10 representation of > + the numeric value of the discretionary > + effective group id of the process that > + is executing the security event. > + > + egid=NN > + The ASCII base 10 representation of > + the numeric value of the discretionary > + effective group id of the process that > + is executing the security event. > + > + sgid=NN > + The base 10 ASCII representation of > + the numeric value of the saved > + discretionary group id of the process > + that is executing the security event. > + > + fsuid=NN > + The base 10 ASCII representation of > + the numeric value of the discretionary > + filesystem user id of the process that > + is executing the security event. > + > + fsgid=NN > + The ASCII base 10 representation of > + the numeric value of the discretionary > + filesystem group id of the process > + that is executing the security event. > + > + cap=0xNNN > + The ASCII base 16 representation of > + the numeric value of effective > + capabilities of the process that is > + executing the security event. > + > + If the CELL value for a security event includes the > + definition of a file a file{} event field will be > + included. The following characteristics will be > + encoded in this field: > + > + flags=NN > + The ASCII base 10 representation of > + the flags value of the 'struct file' > + structure that is the source of the > + file description. > + > + uid=NN > + The ASCII base 10 representation of > + the discretionary user id of the file. > + > + gid=NN > + The base 10 ASCII representation of > + the discretionary group id of the > + file. Similar to the task UID/GID mapping questions above, there are mechanisms which map the file user/group IDs, which will be used in the CELL definition and how will that be resolved between the kernel and an external modeler? > +What: /sys/fs/tsem/ExternalTMA > +Date: November 2022 > +Contact: Greg Wettstein <greg@enjellic.com> > +Description: > + The ExternalTMA directory is a container directory > + that hold files that will be used to export the > + security events, and their associated parameters, for > + externally modeled security domains/namespaces. > + > + The files created in this directory will be named by > + the base 10 ASCII representation of the id value > + assigned to the modeling domain/namespace. See the > + documentation for the /sys/fs/tsem/id file in this > + documentation for more details on this value. > + > + This file will is a read-only file that can be polled > + by a userspace trust orchestration implementation to > + process security events that are to be modeled by > + an external Trusted Modeling Agent. > + > + The type of the exported event is the first keyword of > + the line that is output and have the following > + values and arguments: > + > + aggregate HEXID: > + Where HEXID is the ASCII base 16 > + representation of the 256 bit hardware > + platform aggregate value. > + > + export pid{NNN} COE{} CELL_DEFINITION > + Where the NNN in the pid field is the ASCII > + base 10 value of the id of the process that is > + executing the security event that will be > + modeled. I worry whenever I see a PID used as an identifier shared across the kernel/userspace boundary as it is inherently racy. Given the somewhat coarse COE definition where one can expect multiple processes/PIDs to share the same COE value, and the ability of untrusted users/processes to manipulate the PID table, what do you expect to use the pid{NNN} field for in this event? Similar to the other namespace/mapping issues discussed previously, there is also the PID namespace issue to worry about. How is that handled here? > + The COE field has the same format as the field > + emitted for a trajectory or forensics event. > + > + The CELL_DEFINITION are the same field > + definitions that are emitted for a trajectory > + or forensics event. > + > + log process{name} event{type} action{type} > + The log event is emitted when an untrusted > + task attempts to execute a security event. > + > + The name value of the COE field is the name of > + the process (comm value) that is executing the > + security event. > + > + The type value of the event field is the name > + of the security event being executed as > + defined in the tsem_names array in the > + security/tsem/tsem.c file. > + > + The type value of the action field is the type > + of action the LSM enforced in response to > + encountering the untrusted process. This > + value will be either LOG or EPERM to represent > + whether or not the trust violation is being > + logged or enforced. > + > +What: /sys/fs/tsem/control > +Date: November 2022 > +Contact: Greg Wettstein <greg@enjellic.com> > +Description: > + The control file is the only writable file in the > + filesystem and is used by the trust orchestrators to > + configure and control the behavior of the TSEM > + implementation. > + > + The following keyword and arguments are recognized: > + > + internal: > + The internal keyword causes an internally > + modeled domain to be created for the calling > + process. > + > + external: > + The external keyword causes an externally > + modeled domain to be created for the calling > + process. > + > + enforce: > + The enforce keyword causes the modeling > + domain/namespace of the process to enter > + enforcing mode. In this mode a value of > + -EPERM will be returned for a security event > + that does not map into the current set of > + allowed state points for the security model > + being implemented for the domain/namespace. > + > + seal: > + The seal keyword causes the security model > + being implemented for the model to be placed > + in sealed state. In this state the current > + set of security event points is considered to > + be the only set of valid points for the > + domain/model. Any subsequent events that map > + to a point not in the current model will be > + considered a violation of the model. > + > + trusted PID: > + The trusted keyword is used by a trust > + orchestrator to indicate that the process > + identified by the PID argument should be > + allowed to run in trusted status. > + > + untrusted PID: > + The untrusted keyword is used by a trust > + orchestrator to indicate that the process > + identified by the PID argument should be > + allowed to run but designated as an untrusted > + process. The 'trusted PID:' and 'untrusted PID:' commands are concerning for the reasons described above about PIDs being racy and generally an unreliable way of identifying processes across the kernel/userspace boundary. I suspect it would not be too difficult for a malicious user to trick an external modeler into marking the wrong process as trusted/untrusted. > + state HEXID: > + The state keyword is used to indicate that the > + security state point identified by the ASCII > + base 16 encoded value should be loaded into > + the current security model as a valid security > + event state. > + > + pseudonym HEXID > + The pseudonym keyword is used to indicate that > + the pathname, identified by the 256 bit ASCII > + base 16 encoded value HEXID, should be > + designated to return a constant digest value > + for the contents of the file. > + > + The HEXID value is computed with the following > + function: > + > + HEXID = SHA256(PATHNAME_LENGTH || PATHNAME) This seems like an unusual design choice, and perhaps one born from necessity ... ? It's nice that it is opt-in, but I would be curious to hear what problems this solved. > + base HEXID > + The base keyword is used to indicate that the > + 256 bit ASCII base 16 encoded value HEXID > + should be registered as the value used to > + generate model specific security event points. > + > + A model specific base value is designed to be > + used as a 'freshness' nonce, similar to an > + attestation nonce, to prove that a model state > + value or measurement is current and not being > + replayed. > diff --git a/Documentation/admin-guide/LSM/tsem.rst b/Documentation/admin-guide/LSM/tsem.rst > new file mode 100644 > index 000000000000..f03e5269cd25 > --- /dev/null > +++ b/Documentation/admin-guide/LSM/tsem.rst > @@ -0,0 +1,1240 @@ > +==== > +TSEM > +==== ... > +Process and Platform Trust Status > +================================= > + > +A fundamental concept in TSEM is the notion of providing a precise > +definition for what it means for a platform or workload to be trusted. > +A trusted platform or workload is one where there has not been an > +attempt by a process to execute a security relevant event that does > +not map into a known security state point. > + > +The process trust status is a characteristic of the process that is > +passed to any subordinate processes that are descendants of that > +process. Once a process is tagged as untrusted, that characteristic > +cannot be removed from the process. In a 'fruit from the poisoned > +vine' paradigm, all subordinate processes created by an untrusted > +process are untrusted as well. > + > +On entry into each TSEM security event handler, the trust status of a > +process is checked before an attempt to model the event is made. An > +attempt to execute a security event by an untrusted process will cause > +the event, and its characteristics, to be logged. The return status > +of the hook will be determined by the enforcement state of the model. > +A permission denial is only returned if the TMA is running in > +enforcing mode. > + > +If the platform running the TSEM LSM has a TPM, the hardware aggregate > +value is computed at the time that TSEM is initialized. This hardware > +aggregate value is the linear extension sum over Platform > +Configuration Registers (PCR's) 0 through 7. This is the same > +aggregate value that is computed by the Integrity Measurement > +Architecture (IMA) and is the industry standard method of providing an > +evaluation measurement of the hardware platform state. > + > +Internally model domains have the hardware aggregate measurement > +included as the first state point in the security model. Externally > +modeled domains export the hardware aggregate value to the TMA for > +inclusion as the first state point of the model maintained by the TMA. > + > +The root modeling domain extends each security state point into PCR > +11. This allows hardware based TSEM measurements to coexist with IMA > +measurement values. This hardware measurement value can be used to > +attest to the security execution trajectory that the root model > +maintains. It seems like making the target PCR configurable would be a good idea, at the very least make it a Kconfig option. Also, can you elaborate on how the security state points are extended into the PCR? I imagine for it to be useful at an arbitrary point in time this would require the PCR to be extended as the security points were generated, which would imply that the PCR value would be dependent on execution order, and in most cases, scheduling order as well. How useful do you expect this to be for most users? > +Internal vs external modeling > +----------------------------- > + > +When a TSEM modeling domain is created, a designation is made as to > +whether the domain is to be internally or externally modeled. > + > +In an internally modeled domain, the security event handlers pass the > +event type and its characteristics to the designated internal trusted > +modeling agent. The agent provides the permission value for the > +security event handler to return as the result of the event and sets > +the trust status of the process executing the event. > + > +In an externally modeled domain, the event type and parameters are > +exported to userspace for processing by a trust orchestrator with an > +associated TMA. The trust orchestrator communicates the result of the > +modeling back to the kernel to support the setting of the process > +trust status. > + > +This model poses a limitation to the ability of TSEM to model some > +security events. This is secondary to the fact that some event > +handlers (LSM hooks) are called from a non-sleeping context, as a > +result the process cannot be scheduled. This is particularly the case > +with the task based hooks, since they are typically called with the > +tasklist lock held. > + > +This limitation is also inherent to the root model that extends the > +security state points into TPM PCR 11, secondary to the fact that the > +process invoking the security event hook will be scheduled away while > +the TPM transaction completes. > + > +Addressing this problem directly requires a consideration of the > +context from which the security event handlers are being called. > +Subsequent implementations of TSEM will include a mechanism for > +asynchronous deferral of model processing, until when and if, a review > +of the call context would be considered worthwhile by the LSM > +community. This is a pretty big limitation, and in conjunction with the some of the other issues brought up earlier (the PID issue seems the most concerning), I'm having a difficult time believeing that an external modeler could operate safely given the design presented here. Unfortunately, there will always be LSM hooks which need to operate in a non-blocking context, meaning this challenge is here to stay. Help me understand how you could safely do asynchronous policy enforcement with an external modeler, I'm not sure it's possible. Frankly, I also wonder how a system would perform with an external modeler, indepdent of the issues with non-blocking hooks. How does the system perform with every blockable LSM hook invocation potentially blocking on a response from userspace? Or with the COE being somewhat coarse, does the trajectory/policy populate itself quickly? > +Event handlers that cannot be directly modeled, still consider, on > +entry, whether or not they are being called by an trusted or untrusted > +process. As a result, an untrusted process will cause a non-modeled > +event to return a permissions violation in enforcing mode, even if the > +security event cannot be directly modeled. > + > +Security event modeling typically traps violations of trust by a COE > +with unmodeled characteristics that is attempting to access/execute a > +file or map memory as executable; or by a COE with known > +characteristics attempting to access or execute a CELL not prescribed > +by a model. As a result, the impact of the ability to not directly > +model these events is lessened. ... > +Event modeling > +-------------- > + > +TSEM security event modeling is based on the following functional > +definition for a security state point: > + > +Sp = SHA256(SHA256(EVENT_ID) || TASK_ID || SHA256(COE) || SHA256(CELL)) It appears that all of the hasing in TSEM is SHA256 based, you might want to consider making that a Kconfig option at the very least. > + Where: > + || = Concatenation operator. > + > + EVENT_ID = ASCII name of event. > + > + TASK_ID = 256 bit identity of the process executing > + the security event. > + > + COE = Characteristics of the context of execution > + of the event. > + > + CELL = Characteristics of the object that the > + security event is acting on. > +
On Sun, Feb 12, 2023 at 11:33:26PM -0500, Paul Moore wrote: > On Sat, Feb 4, 2023 at 12:33 AM Dr. Greg <greg@enjellic.com> wrote: > > > > An entry was added to the ABI testing documentation to document > > the files in the TSEM management filesystem. > > > > The file documenting the kernel command-line parameters was > > updated to document the tsem_mode command-line parameter. > > > > The primary TSEM documentation file was added to the LSM > > administration guide and the file was linked to the index of LSM > > documentation. > > > > Signed-off-by: Greg Wettstein <greg@enjellic.com> > > --- > > Documentation/ABI/testing/tsemfs | 576 ++++++++ > > Documentation/admin-guide/LSM/index.rst | 1 + > > Documentation/admin-guide/LSM/tsem.rst | 1240 +++++++++++++++++ > > .../admin-guide/kernel-parameters.txt | 5 + > > 4 files changed, 1822 insertions(+) > > create mode 100644 Documentation/ABI/testing/tsemfs > > create mode 100644 Documentation/admin-guide/LSM/tsem.rst > One of the more important requirements for any new LSM is that it > documents a clear, understandable, and reasonable security model along > with an implementation that faithfully implements that model. Before > I looked at your code I wanted to try and understand the TSEM security > model and a few things jumped out at me rather quickly, I imagine > there would be others as I start to look a bit closer but I wanted to > send these questions/comments along now to get your take on them ... Hi Paul, thanks for taking time to review the documentation and raise questions, responses below. > > diff --git a/Documentation/ABI/testing/tsemfs b/Documentation/ABI/testing/tsemfs > > new file mode 100644 > > index 000000000000..3d326934624c > > --- /dev/null > > +++ b/Documentation/ABI/testing/tsemfs > > @@ -0,0 +1,576 @@ > > ... > > > +What: /sys/fs/tsem/aggregate > > +Date: November 2022 > > +Contact: Greg Wettstein <greg@enjellic.com> > > +Description: > > + The aggregate file contains the ASCII base 16 > > + representation of the 256 bit hardware platform > > + aggregate that TSEM is modeling under. The platform > > + aggregate is the extension measurement of the Trusted > > + Platform Module PCR registers 0 through 8. > I'm guessing the above is a typo and you mean PCRs 0 through 7 (not > 8)? If not, you need to provide an explanation somewhere as to what > you are using PCR 8 for in TSEM and how it is extended, etc. You are correct, it was a typo, it is registers 0 through 7, classic zero counted array error.... :-) We verified that the implementation is indeed aggregating registers 0 through 7. > > +What: /sys/fs/tsem/measurement > > +Date: November 2022 > > +Contact: Greg Wettstein <greg@enjellic.com> > > +Description: > > + The measurement file contains the ASCII base 16 > > + hexadecimal representation of the 256 bit measurement > > + value of the security model that the process is > > + operating in. > > + > > + The measurement value is the classic linear extension > > + measurement of the model. An updated measurement > > + value is created by extending the current measurement > > + value with the state coefficient computed for a > > + security event. > > + > > + This measurement value represents a time dependent > > + measurement of a model and is susceptible to > > + deviations caused by scheduling differences between > > + subsequent invocations of a workload. > Given the very volatile nature of this value, what is it used for in > userspace? My apologies if I missed it in the docs. It serves the same role as PCR register 10 in IMA, or any other register in a TPM based architecture using a classic linear extension mechanism strategy, it can be used to validate a list of time or sequence ordered measurement values. Our personal prejudice is that these types of measurements are of limited value, which is why we introduce in TSEM, the notion of the 'state' value for a model, discussed below. I would have to go looking on lore for a reference to the exact thread but Roberto Sassu had offered up a patch set for IMA that addressed the deficiency of these types of measurements. > > +What: /sys/fs/tsem/points > > +Date: November 2022 > > +Contact: Greg Wettstein <greg@enjellic.com> > > +Description: > > + The points file contains the ASCII base 16 > > + representation of the 256 bit security state points of > > + a security domain/model. The number of entries in > > + this file represent the number of security events that > > + are represented by the model. > A similar questions to the tsem/measurement file. If I understand > you correctly, this is basically a series of SHA256 digests without > any additional annotations, and without any ordering guarantees, > yes? What is it used for in userspace? The values in the points file represent the current state of a model, they are the coefficients that describe the security events that have been modeled. The output of this file can be captured and written to the /sys/fs/tsem/map file in order to define a security model that is to be subsequently enforced. > > +What: /sys/fs/tsem/state > > +Date: November 2022 > > +Contact: Greg Wettstein <greg@enjellic.com> > > +Description: > > + The state file contains the ASCII base 16 > > + representation of the 256 bit value of the functional > > + state of a security domain/model. > > + > > + The state value is a time independent representation > > + of the measurement of a model/domain, and unlike the > > + measurement value, is a time independent > > + representation of the security state of a workload. > > + > > + This value is designed to be a single value that can > > + be attested to represent whether or not a workload has > > + deviated from a defined security behavior. > It might be nice to explain how this value is calculated here in > this file to remove any time or ordering dependencies. Once again > my apologies if I missed it in the rest of the docs. The TSEM LSM documentation covers the issues surrounding the measurement and state values. See the section entitled 'Security model functional definitions'. Put succinctly, the state value is computed by generating a standard linear extension sum over a list of security state points that have been sorted in big-endian, ie. natural hash order. It is designed to provide a time and scheduling independent value that can be used to attest that a security model has not violated its definition. Don't apologize, there is a lot there to read, our loquaciousness knows no bounds.... :-) > > +What: /sys/fs/tsem/trajectory > > +Date: November 2022 > > +Contact: Greg Wettstein <greg@enjellic.com> > > +Description: > > + The trajectory file contains a description of the > > + security events that have occurred in a security > > + domain/model. > > + > > + Each entry in this file represents a single security > > + event and consists of brace {} delimited fields that > > + describe the characteristics of a security event. > > + Each field has key=value pairs that define > > + characteristics of the field. > > + > > + Each line in a trajectory, or forensics, file will > > + always have the event{} and COE{} fields. The event > > + field describes the characteristics of a security > > + event while the COE field describes the Context Of > > + Execution that is executing the security event. > I think it would be good to provide a concrete definition of > CELL_DEFINITION field as other areas of the documentation make > reference to it within the tsem/trajectory file documentation. We can > somewhat infer it's format, fields, etc. but it's much better to be > explicit about these things. Valid point, we will incorporate a broad definition of what the 'CELL' represents. Conceptually, it is equivalent to the 'object' in mandatory access controls. In an events based architecture like TSEM, it is essentially the 'bucket' of values that describe the parameters of a security event that a COE/process is requesting permission for. The name is actually in deference to Turing theory, which all of this relates back to, but no need to go there now. > > + The event{} field consists of the following > > + characteristic definitions: > I'm unclear as to the purpose of the event{} field as it is neither > part of the COE or the CELL, is it here simply to make the event > easier to read? Or am I misunderstanding things and the event{} > field is part of the COE? It actually serves two roles, one of which, as you note, is to make the event description easier to read and understand. It probably comes as no surprise, but the trust orchestration system that this is all designed to support, has a security console that can be used to review the status of all the trust orchestrators that are supervising security workloads. Either in the cloud, or perhaps, a large body of edge devices protecting critical infrastructure, if that doesn't give away too much.... :-) Having the process name and executable easily visualized is fairly useful. The second role is to allow the event description records to be self-describing. The value for the type= key is used by the Trusted Modeling Agent (TMA) to determine what to look for in the remainder of the event description record in order to compute the CELL value. It also contains the TASK_ID value that ties the security state points to the integrity of the executable. Since that value is a synthetic value it was deemed most appropriate to be placed in the event{} field. > > + process=COMM > > + Where COMM is the ASCII representation > > + of the name of the process executing > > + the event. > > + > > + filename=PATH > > + If the CELL definition for an event > > + references a file the filename > > + characteristic contains a definition > > + of the path to the file. > > + > > + In the case where an event does not > > + have a file the PATH value is set to a > > + value of none. > What happens in cases where multiple file paths are present in an > event? Also, given this is visible to userspace, and multiple > things can affect the path to a file (e.g. namespaces), how is the > file path determined? Unless we have missed something, which is no doubt possible, all of the security event hooks that we have implemented, which number about 87 now, that act on a 'file', receive only a single 'struct file *' pointer as a parameter to the event. So we haven't encountered a situation where there would be multiple files for a single event description. There is certainly the case where multiple security state points involve the same file. This can easily be seen, for example, in a trust orchestrator running a workload in a runc container, where multiple state points are generated by different executable mappings of the runc binary at startup The file path is the absolute pathname in the mount namespace that the modeled workload is running in. See the following for details: security/tsem/event.c:get_path() > > + type=EVENT_TYPE > > + The value field for a type key is the > > + name of the security event that is > > + being modeled. The list of value > > + EVENT_TYPE names is defined in the > > + following source file: > > + > > + security/tsem/tsem.c > > + > > + If the security event is a generically > > + modeled event the EVENT_TYPE will be > > + generic_event. In this case the CELL > > + characteristics for the event will be > > + described by a generic_event{} field. > > + > > + task_id=TASK_ID > > + The value of the task_id key will the > > + ASCII base 16 representation of the > > + model identity of the task that is > > + executing the security event. > > + > > + The following documentation file: > > + > > + Documentation/admin-guide/LSM/TSEM.rst > > + > > + Describes how the TASK_ID value is > > + generated. > > + > > + The COE{} field consists of the following > > + characteristic definitions: > > + > > + uid=NN > > + The ASCII base 10 representation of > > + the numeric value of the discretionary > > + user id of the process that is > > + executing the security event. > Given the ability to map UID/GID values in the kernel, what will be > used as the basis for the COE? What happens when the basis used in > the kernel's COE generation does not match the basis used by the > external modeler? The UID/GID values used are the values defined in the initial user namespace, see security/tsem/event.c:get_COE(). The basis set state that the trust orchestrator is running in has no effect on the generation of the security state point. The modeling engine only operates on the values presented to it and determines if the state point generated from the state description matches the model it has been requested to enforce. If it doesn't, the event is considered to violate the trust model. > > + euid=NN > > + The ASCII base 10 representation of > > + the numeric value of the effective > > + discretionary user id of the process > > + that is executing the security event. > > + > > + euid=NN > > + The ASCII base 10 representation of > > + the numeric value of the effective > > + discretionary user id of the process > > + that is executing the security event. > > + > > + suid=NN > > + The ASCII base 10 representation of > > + the numeric value of the saved user id > > + of the process that is executing the > > + security event. > > + > > + gid=NN > > + The ASCII base 10 representation of > > + the numeric value of the discretionary > > + group id of the process that is > > + executing the security event. > > + > > + egid=NN > > + The ASCII base 10 representation of > > + the numeric value of the discretionary > > + effective group id of the process that > > + is executing the security event. > > + > > + egid=NN > > + The ASCII base 10 representation of > > + the numeric value of the discretionary > > + effective group id of the process that > > + is executing the security event. > > + > > + sgid=NN > > + The base 10 ASCII representation of > > + the numeric value of the saved > > + discretionary group id of the process > > + that is executing the security event. > > + > > + fsuid=NN > > + The base 10 ASCII representation of > > + the numeric value of the discretionary > > + filesystem user id of the process that > > + is executing the security event. > > + > > + fsgid=NN > > + The ASCII base 10 representation of > > + the numeric value of the discretionary > > + filesystem group id of the process > > + that is executing the security event. > > + > > + cap=0xNNN > > + The ASCII base 16 representation of > > + the numeric value of effective > > + capabilities of the process that is > > + executing the security event. > > + > > + If the CELL value for a security event includes the > > + definition of a file a file{} event field will be > > + included. The following characteristics will be > > + encoded in this field: > > + > > + flags=NN > > + The ASCII base 10 representation of > > + the flags value of the 'struct file' > > + structure that is the source of the > > + file description. > > + > > + uid=NN > > + The ASCII base 10 representation of > > + the discretionary user id of the file. > > + > > + gid=NN > > + The base 10 ASCII representation of > > + the discretionary group id of the > > + file. > Similar to the task UID/GID mapping questions above, there are > mechanisms which map the file user/group IDs, which will be used in > the CELL definition and how will that be resolved between the kernel > and an external modeler? The answer is the same as with the COE, see the following function: security/tsem/event.c:get_file_cell() Once again, the TMA only operates on the event description presented to it and is not influenced by its own namespace. > > +What: /sys/fs/tsem/ExternalTMA > > +Date: November 2022 > > +Contact: Greg Wettstein <greg@enjellic.com> > > +Description: > > + The ExternalTMA directory is a container directory > > + that hold files that will be used to export the > > + security events, and their associated parameters, for > > + externally modeled security domains/namespaces. > > + > > + The files created in this directory will be named by > > + the base 10 ASCII representation of the id value > > + assigned to the modeling domain/namespace. See the > > + documentation for the /sys/fs/tsem/id file in this > > + documentation for more details on this value. > > + > > + This file will is a read-only file that can be polled > > + by a userspace trust orchestration implementation to > > + process security events that are to be modeled by > > + an external Trusted Modeling Agent. > > + > > + The type of the exported event is the first keyword of > > + the line that is output and have the following > > + values and arguments: > > + > > + aggregate HEXID: > > + Where HEXID is the ASCII base 16 > > + representation of the 256 bit hardware > > + platform aggregate value. > > + > > + export pid{NNN} COE{} CELL_DEFINITION > > + Where the NNN in the pid field is the ASCII > > + base 10 value of the id of the process that is > > + executing the security event that will be > > + modeled. > I worry whenever I see a PID used as an identifier shared across the > kernel/userspace boundary as it is inherently racy. Given the > somewhat coarse COE definition where one can expect multiple > processes/PIDs to share the same COE value, and the ability of > untrusted users/processes to manipulate the PID table, what do you > expect to use the pid{NNN} field for in this event? > > Similar to the other namespace/mapping issues discussed previously, > there is also the PID namespace issue to worry about. How is that > handled here? The concern over the PID issue is understandable, I will treat the reasoning behind its use below. The PID value is the 'native' value managed by the kernel, not a mapped value. > > + The COE field has the same format as the field > > + emitted for a trajectory or forensics event. > > + > > + The CELL_DEFINITION are the same field > > + definitions that are emitted for a trajectory > > + or forensics event. > > + > > + log process{name} event{type} action{type} > > + The log event is emitted when an untrusted > > + task attempts to execute a security event. > > + > > + The name value of the COE field is the name of > > + the process (comm value) that is executing the > > + security event. > > + > > + The type value of the event field is the name > > + of the security event being executed as > > + defined in the tsem_names array in the > > + security/tsem/tsem.c file. > > + > > + The type value of the action field is the type > > + of action the LSM enforced in response to > > + encountering the untrusted process. This > > + value will be either LOG or EPERM to represent > > + whether or not the trust violation is being > > + logged or enforced. > > + > > +What: /sys/fs/tsem/control > > +Date: November 2022 > > +Contact: Greg Wettstein <greg@enjellic.com> > > +Description: > > + The control file is the only writable file in the > > + filesystem and is used by the trust orchestrators to > > + configure and control the behavior of the TSEM > > + implementation. > > + > > + The following keyword and arguments are recognized: > > + > > + internal: > > + The internal keyword causes an internally > > + modeled domain to be created for the calling > > + process. > > + > > + external: > > + The external keyword causes an externally > > + modeled domain to be created for the calling > > + process. > > + > > + enforce: > > + The enforce keyword causes the modeling > > + domain/namespace of the process to enter > > + enforcing mode. In this mode a value of > > + -EPERM will be returned for a security event > > + that does not map into the current set of > > + allowed state points for the security model > > + being implemented for the domain/namespace. > > + > > + seal: > > + The seal keyword causes the security model > > + being implemented for the model to be placed > > + in sealed state. In this state the current > > + set of security event points is considered to > > + be the only set of valid points for the > > + domain/model. Any subsequent events that map > > + to a point not in the current model will be > > + considered a violation of the model. > > + > > + trusted PID: > > + The trusted keyword is used by a trust > > + orchestrator to indicate that the process > > + identified by the PID argument should be > > + allowed to run in trusted status. > > + > > + untrusted PID: > > + The untrusted keyword is used by a trust > > + orchestrator to indicate that the process > > + identified by the PID argument should be > > + allowed to run but designated as an untrusted > > + process. > The 'trusted PID:' and 'untrusted PID:' commands are concerning for > the reasons described above about PIDs being racy and generally an > unreliable way of identifying processes across the kernel/userspace > boundary. I suspect it would not be too difficult for a malicious > user to trick an external modeler into marking the wrong process as > trusted/untrusted. An external TMA needs the PID value to determine which process to wake up and set the trust status value on in the task control structure, after the event is modeled. As was noted above, the PID value is the unmapped value maintained by the OS. Lets see if we can reason through why the PID can be used safely. CAP_TRUST, or whatever ends up getting used, is required by the trust orchestrator to create a security/modeling namespace for the workload being modeled. This results in the creation of the following pseudo-file for surfacing the security event descriptions for the namespace/workload: /sys/fs/tsem/ExternalTMA/N Where N is the id number of the modeling domain. CAP_TRUST, caveats applied, is required to open the pseudo-file. The trust orchestrator only receives and acts on PID values through this conduit from the kernel. When an event description is exported, the trust status of the task is set to 'pending' and the process is placed in interruptible sleep and scheduled away, with the 'wakeup' criteria being the trust status being changed from pending to either trusted or untrusted. The only path to change the trust status value in the LSM task control structure and wake up the process is by the trust orchestrator that created the namespace, by writing the appropriate value to the /sys/fs/tsem/control file. Access to that file is gated by CAP_TRUST or its equivalent. See the following code locations for further details: security/tsem/export.c:tsem_export_event() security/tsem/fs.c:control_COE() As long as the process 'exists', albeit sleeping, the PID slot is occupied and an adversary, regardless of namespace, cannot substitute a task with the same PID value. This leaves an adversary with the need to terminate the task being modeled in order to capture its PID slot. Precautions are implemented in the following function to protect the process from being terminated by an adversary: security/tsem/tsem.c:tsem_task_kill() The following is a summary of the criteria that is implemented: - Signal privileges are granted to any process with CAP_TRUST. - A process without CAP_TRUST cannot signal a process with CAP_TRUST. - Cross-model signaling is denied by a process without CAP_TRUST. So that leaves us in a scenario where, outside of the modeling namespace, CAP_TRUST would be required to kill the process waiting to be modeled. If CAP_TRUST has been lost to an adversary, the platform is owned and the game is over. So that leaves us with the threat of an adversary attempting to implement a PID race within the modeling domain itself. As I've noted previously in these threads, and in the LSM documentation proper, TSEM is about prospective generation of a security model, rather than retrospective correction of a MAC policy that has been demonstrated to have undesired effects. The distinction is important in this case. For an adversary to mount a PID race attack from within the modeled workload, one of three conditions must be met: - A shell script is read. - A malicious binary would have to be executed. - Memory would have had to have been mapped executable. Since TSEM captures the security events needed to implement these actions, the events would have had to have been incorporated into the security unit test for the workload or the actions would be denied. Hopefully this analysis is complete and correct with respect to this threat, comments and observations are obviously welcome. There is an opportunity to strengthen this model that I will touch on below. > > + state HEXID: > > + The state keyword is used to indicate that the > > + security state point identified by the ASCII > > + base 16 encoded value should be loaded into > > + the current security model as a valid security > > + event state. > > + > > + pseudonym HEXID > > + The pseudonym keyword is used to indicate that > > + the pathname, identified by the 256 bit ASCII > > + base 16 encoded value HEXID, should be > > + designated to return a constant digest value > > + for the contents of the file. > > + > > + The HEXID value is computed with the following > > + function: > > + > > + HEXID = SHA256(PATHNAME_LENGTH || PATHNAME) > This seems like an unusual design choice, and perhaps one born from > necessity ... ? It's nice that it is opt-in, but I would be curious > to hear what problems this solved. It is an approximation method that allows things like log files and .bash_history files to be effectively modeled. Once again, TSEM is a blending of integrity measurement and mandatory access controls. In a security event that has a file as a component of its CELL, the SHA256 digest value of the file is included in the computation of the CELL identity. These types of files have no known 'good' value, by definition. So 'pseudonym' declarations implement a model approximation to provide a fixed digest value for a file, regardless of its contents. The effect of this can easily be seen if one of the Quixote trust orchestrators is used to run a container based shell workload. If the .bash_history file in the container is not zeroed before execution, or treated as a pseudonym, the bash shell will be tagged and 'poisoned' as untrusted when it reads the file. It is a pretty solid understanding in modeling theory that approximations are almost universally required when dealing with physical phenomenon. As a quantum chemist by training, I spent a fair amount of time dealing with complete, intermediate and modified neglect of diatomic overlap as a result of this.... :-) > > + base HEXID > > + The base keyword is used to indicate that the > > + 256 bit ASCII base 16 encoded value HEXID > > + should be registered as the value used to > > + generate model specific security event points. > > + > > + A model specific base value is designed to be > > + used as a 'freshness' nonce, similar to an > > + attestation nonce, to prove that a model state > > + value or measurement is current and not being > > + replayed. > > diff --git a/Documentation/admin-guide/LSM/tsem.rst b/Documentation/admin-guide/LSM/tsem.rst > > new file mode 100644 > > index 000000000000..f03e5269cd25 > > --- /dev/null > > +++ b/Documentation/admin-guide/LSM/tsem.rst > > @@ -0,0 +1,1240 @@ > > +==== > > +TSEM > > +==== > > ... > > > +Process and Platform Trust Status > > +================================= > > + > > +A fundamental concept in TSEM is the notion of providing a precise > > +definition for what it means for a platform or workload to be trusted. > > +A trusted platform or workload is one where there has not been an > > +attempt by a process to execute a security relevant event that does > > +not map into a known security state point. > > + > > +The process trust status is a characteristic of the process that is > > +passed to any subordinate processes that are descendants of that > > +process. Once a process is tagged as untrusted, that characteristic > > +cannot be removed from the process. In a 'fruit from the poisoned > > +vine' paradigm, all subordinate processes created by an untrusted > > +process are untrusted as well. > > + > > +On entry into each TSEM security event handler, the trust status of a > > +process is checked before an attempt to model the event is made. An > > +attempt to execute a security event by an untrusted process will cause > > +the event, and its characteristics, to be logged. The return status > > +of the hook will be determined by the enforcement state of the model. > > +A permission denial is only returned if the TMA is running in > > +enforcing mode. > > + > > +If the platform running the TSEM LSM has a TPM, the hardware aggregate > > +value is computed at the time that TSEM is initialized. This hardware > > +aggregate value is the linear extension sum over Platform > > +Configuration Registers (PCR's) 0 through 7. This is the same > > +aggregate value that is computed by the Integrity Measurement > > +Architecture (IMA) and is the industry standard method of providing an > > +evaluation measurement of the hardware platform state. > > + > > +Internally model domains have the hardware aggregate measurement > > +included as the first state point in the security model. Externally > > +modeled domains export the hardware aggregate value to the TMA for > > +inclusion as the first state point of the model maintained by the TMA. > > + > > +The root modeling domain extends each security state point into PCR > > +11. This allows hardware based TSEM measurements to coexist with IMA > > +measurement values. This hardware measurement value can be used to > > +attest to the security execution trajectory that the root model > > +maintains. > It seems like making the target PCR configurable would be a good > idea, at the very least make it a Kconfig option. That was something that we have thought about, it probably needs a Kconfig option. Contrary to all appearances, as a team we are really minimalists at heart and tend to not make things more complex or configurable than needed.... :-) > Also, can you elaborate on how the security state points are > extended into the PCR? I imagine for it to be useful at an > arbitrary point in time this would require the PCR to be extended as > the security points were generated, which would imply that the PCR > value would be dependent on execution order, and in most cases, > scheduling order as well. How useful do you expect this to be for > most users? Your assessment is correct, the state points are extended into the PCR whenever a unique security state point is generated. In a 'free-running' model, the value in the register will be fungible due to scheduling dependencies. If the model is pre-defined, the security state points will be extended into the register as they are loaded through the /sys/fs/tsem/map pseudo-file interface. In this case, the value will be fixed and any departure from the value would signal that the modeling domain has departed from its specification. With respect to the utility of the value, in a 'free-running' model it is about as useful as the value that IMA maintains in PCR 10, which in our opinion is not very useful and is why we implemented the notion of the 'state' value of a model. The primary utility of the value is that it is a hardware maintained reference value that can be used to confirm the set of measurements committed to the register. So our 'state' value gives us a constant 'good' value for the security model. The PCR 11 value provides a hardware root of trust for the set of points that lead to the state value. > > +Internal vs external modeling > > +----------------------------- > > + > > +When a TSEM modeling domain is created, a designation is made as to > > +whether the domain is to be internally or externally modeled. > > + > > +In an internally modeled domain, the security event handlers pass the > > +event type and its characteristics to the designated internal trusted > > +modeling agent. The agent provides the permission value for the > > +security event handler to return as the result of the event and sets > > +the trust status of the process executing the event. > > + > > +In an externally modeled domain, the event type and parameters are > > +exported to userspace for processing by a trust orchestrator with an > > +associated TMA. The trust orchestrator communicates the result of the > > +modeling back to the kernel to support the setting of the process > > +trust status. > > + > > +This model poses a limitation to the ability of TSEM to model some > > +security events. This is secondary to the fact that some event > > +handlers (LSM hooks) are called from a non-sleeping context, as a > > +result the process cannot be scheduled. This is particularly the case > > +with the task based hooks, since they are typically called with the > > +tasklist lock held. > > + > > +This limitation is also inherent to the root model that extends the > > +security state points into TPM PCR 11, secondary to the fact that the > > +process invoking the security event hook will be scheduled away while > > +the TPM transaction completes. > > + > > +Addressing this problem directly requires a consideration of the > > +context from which the security event handlers are being called. > > +Subsequent implementations of TSEM will include a mechanism for > > +asynchronous deferral of model processing, until when and if, a review > > +of the call context would be considered worthwhile by the LSM > > +community. > This is a pretty big limitation, and in conjunction with the some of > the other issues brought up earlier (the PID issue seems the most > concerning), I'm having a difficult time believeing that an external > modeler could operate safely given the design presented here. With respect to the PID issue, we would welcome any comments on the analysis that we provided above as to its design safety. If the PID issue remains a concern, we have an extension to the export descriptions that would include a random nonce that would be emitted with the PID. The nonce would be placed in the LSM task control 'blob' for the sleeping task and used to confirm that the task release directive was acting on the correct process. > Unfortunately, there will always be LSM hooks which need to operate > in a non-blocking context, meaning this challenge is here to stay. > Help me understand how you could safely do asynchronous policy > enforcement with an external modeler, I'm not sure it's possible. Electing to implement asynchronous enforcement would require further thought. We were operating in the context of full disclosure in our documentation and wanted to be up front about limitations and options. To be clear, at this time, we are not advocating for or bringing forward an asynchronous update architecture. So, at this time, there is a well understood modeling limitation with respect to the LSM hook implementations. That limitation is not limited to external TMA's, since the event state points cannot be extended into a TPM in a non-blocking context. So far we have only run into a handful of these events, almost exclusively due to the LSM hooks being called with the tasklist lock held. I see that Linus commented a couple of weeks ago that the tasklist lock is our last big lock that may need to be looked at. With respect to the need for external modeling, as is the case with all security designs, this is a cost/benefit decision. In some cases, for example SGX, using external modeling is the only option, since executing in the context of an SGX enclave is not possible from the kernel. Quixote/TSEM is actually one of the unsung 'killer' applications for SGX, at least from our long involvement with the technology. Having an external modeling option also means that you don't need to get code into the kernel proper in order to implement a security model that may be useful. I think we all can appreciate the utility and importance of that. We believe that the ability to do dedicated hardware security co-processors is important. External modeling opens the door to democratize how that can be done. The binary Quixote distribution includes firmware for an NRF52840-DONGLE implementation of a TMA. So you have a clear demonstration of the opportunity to create 'Yubikey' type devices to enforce kernel security. A reasonably interesting option for entities distributing dedicated Linux based devices, where for a few dollars you can include a USB based co-processor that would provide hardware based protections to prevent an embedded Linux implementation from being diverted from its design intent. Truth be told, after having looked at countless execution trajectories, processes are typically locked into untrusted status before they get to any of the non-blocking hooks. > Frankly, I also wonder how a system would perform with an external > modeler, indepdent of the issues with non-blocking hooks. How does > the system perform with every blockable LSM hook invocation > potentially blocking on a response from userspace? Or with the COE > being somewhat coarse, does the trajectory/policy populate itself > quickly? One obviously experiences a latency hit in going to userspace, by definition, implementing security always has an associated resource cost. So, once again, this comes down to a cost/benefit analysis. As a Gedanken exercise, consider the value proposition of a Linux based RTU, or other device, controlling infrastructure that can only execute security relevant events that are guaranteed to be known good by an external co-processor that is only accessible as a security oracle. Given that frame of reference. Time for a userspace or SGX based TMA transaction is running around 890 micro-seconds. Going to a TMA based in a Xen stubdomain implementation runs a bit longer, probably around 940 micro-seconds or so. The micro-controller implementations are decidedly slower, with the NRF52840-DONGLE clocking in at around 40 micro-seconds, but that is strictly a CPU horsepower issue. All of this with the caveat that we have been focusing almost exclusively on correctness and not optimizing performance. We've thought a bit, mainly on long walks with our Golden Retriever Izzy, about the issue of building a kernel based policy cache with externally modeled domains. Given that the kernel does not, a-priori, know what modeling algorithm a TMA might be using, we would need to come up with a method of deterministically mapping a security event description to a known good state point value. The other issue with all this is that with containerized workloads, particularly micro-services, the rate of security event generation can be surprisingly low. Obviously this is also the case with embedded implementations. Once again, what are you willing to pay to be safe? > > +Event handlers that cannot be directly modeled, still consider, on > > +entry, whether or not they are being called by an trusted or untrusted > > +process. As a result, an untrusted process will cause a non-modeled > > +event to return a permissions violation in enforcing mode, even if the > > +security event cannot be directly modeled. > > + > > +Security event modeling typically traps violations of trust by a COE > > +with unmodeled characteristics that is attempting to access/execute a > > +file or map memory as executable; or by a COE with known > > +characteristics attempting to access or execute a CELL not prescribed > > +by a model. As a result, the impact of the ability to not directly > > +model these events is lessened. > > ... > > > +Event modeling > > +-------------- > > + > > +TSEM security event modeling is based on the following functional > > +definition for a security state point: > > + > > +Sp = SHA256(SHA256(EVENT_ID) || TASK_ID || SHA256(COE) || SHA256(CELL)) > It appears that all of the hasing in TSEM is SHA256 based, you might > want to consider making that a Kconfig option at the very least. That has been something that we have talked about as well. As I indicated previously, we really are minimalists, particularly after watching IMA fight with issues surrounding algorithmic agility. It would be easy enough to make this configurable but does anyone see SHA256 as not being useful in in this role anywhere in the next 10 years? > paul-moore.com Hopefully all of this is useful moving forward. Have a good day. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity
On Tue, 2023-02-14 at 05:58 -0600, Dr. Greg wrote: > On Sun, Feb 12, 2023 at 11:33:26PM -0500, Paul Moore wrote: > > On Sat, Feb 4, 2023 at 12:33 AM Dr. Greg <greg@enjellic.com> wrote: > > > An entry was added to the ABI testing documentation to document > > > the files in the TSEM management filesystem. > > > > > > The file documenting the kernel command-line parameters was > > > updated to document the tsem_mode command-line parameter. > > > > > > The primary TSEM documentation file was added to the LSM > > > administration guide and the file was linked to the index of LSM > > > documentation. > > > > > > Signed-off-by: Greg Wettstein <greg@enjellic.com> > > > --- > > > Documentation/ABI/testing/tsemfs | 576 ++++++++ > > > Documentation/admin-guide/LSM/index.rst | 1 + > > > Documentation/admin-guide/LSM/tsem.rst | 1240 +++++++++++++++++ > > > .../admin-guide/kernel-parameters.txt | 5 + > > > 4 files changed, 1822 insertions(+) > > > create mode 100644 Documentation/ABI/testing/tsemfs > > > create mode 100644 Documentation/admin-guide/LSM/tsem.rst > > One of the more important requirements for any new LSM is that it > > documents a clear, understandable, and reasonable security model along > > with an implementation that faithfully implements that model. Before > > I looked at your code I wanted to try and understand the TSEM security > > model and a few things jumped out at me rather quickly, I imagine > > there would be others as I start to look a bit closer but I wanted to > > send these questions/comments along now to get your take on them ... > > Hi Paul, thanks for taking time to review the documentation and raise > questions, responses below. > > > > diff --git a/Documentation/ABI/testing/tsemfs b/Documentation/ABI/testing/tsemfs > > > new file mode 100644 > > > index 000000000000..3d326934624c > > > --- /dev/null > > > +++ b/Documentation/ABI/testing/tsemfs > > > @@ -0,0 +1,576 @@ > > > > ... > > > > > +What: /sys/fs/tsem/aggregate > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The aggregate file contains the ASCII base 16 > > > + representation of the 256 bit hardware platform > > > + aggregate that TSEM is modeling under. The platform > > > + aggregate is the extension measurement of the Trusted > > > + Platform Module PCR registers 0 through 8. > > I'm guessing the above is a typo and you mean PCRs 0 through 7 (not > > 8)? If not, you need to provide an explanation somewhere as to what > > you are using PCR 8 for in TSEM and how it is extended, etc. > > You are correct, it was a typo, it is registers 0 through 7, classic > zero counted array error.... :-) > > We verified that the implementation is indeed aggregating registers 0 > through 7. > > > > +What: /sys/fs/tsem/measurement > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The measurement file contains the ASCII base 16 > > > + hexadecimal representation of the 256 bit measurement > > > + value of the security model that the process is > > > + operating in. > > > + > > > + The measurement value is the classic linear extension > > > + measurement of the model. An updated measurement > > > + value is created by extending the current measurement > > > + value with the state coefficient computed for a > > > + security event. > > > + > > > + This measurement value represents a time dependent > > > + measurement of a model and is susceptible to > > > + deviations caused by scheduling differences between > > > + subsequent invocations of a workload. > > Given the very volatile nature of this value, what is it used for in > > userspace? My apologies if I missed it in the docs. > > It serves the same role as PCR register 10 in IMA, or any other > register in a TPM based architecture using a classic linear extension > mechanism strategy, it can be used to validate a list of time or > sequence ordered measurement values. > > Our personal prejudice is that these types of measurements are of > limited value, which is why we introduce in TSEM, the notion of the > 'state' value for a model, discussed below. > > I would have to go looking on lore for a reference to the exact thread > but Roberto Sassu had offered up a patch set for IMA that addressed > the deficiency of these types of measurements. Hi Greg yes, this: https://lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@huawei.com/ DIGLIM makes the PCR extended with software measurements deterministic, independent from how processes are scheduled, at the cost of not knowing if files with matching digests from a list were accessed or not, and in which order. But, in exchange, you can seal a TLS key to IMA measurements that is available for handshakes as long as the system does not execute something unknown. After that, you have to reboot to use the key again. (Didn't read your proposal yet.) Roberto > > > +What: /sys/fs/tsem/points > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The points file contains the ASCII base 16 > > > + representation of the 256 bit security state points of > > > + a security domain/model. The number of entries in > > > + this file represent the number of security events that > > > + are represented by the model. > > A similar questions to the tsem/measurement file. If I understand > > you correctly, this is basically a series of SHA256 digests without > > any additional annotations, and without any ordering guarantees, > > yes? What is it used for in userspace? > > The values in the points file represent the current state of a model, > they are the coefficients that describe the security events that have > been modeled. > > The output of this file can be captured and written to the > /sys/fs/tsem/map file in order to define a security model that is to > be subsequently enforced. > > > > +What: /sys/fs/tsem/state > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The state file contains the ASCII base 16 > > > + representation of the 256 bit value of the functional > > > + state of a security domain/model. > > > + > > > + The state value is a time independent representation > > > + of the measurement of a model/domain, and unlike the > > > + measurement value, is a time independent > > > + representation of the security state of a workload. > > > + > > > + This value is designed to be a single value that can > > > + be attested to represent whether or not a workload has > > > + deviated from a defined security behavior. > > It might be nice to explain how this value is calculated here in > > this file to remove any time or ordering dependencies. Once again > > my apologies if I missed it in the rest of the docs. > > The TSEM LSM documentation covers the issues surrounding the > measurement and state values. See the section entitled 'Security > model functional definitions'. > > Put succinctly, the state value is computed by generating a standard > linear extension sum over a list of security state points that have > been sorted in big-endian, ie. natural hash order. > > It is designed to provide a time and scheduling independent value that > can be used to attest that a security model has not violated its > definition. > > Don't apologize, there is a lot there to read, our loquaciousness > knows no bounds.... :-) > > > > +What: /sys/fs/tsem/trajectory > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The trajectory file contains a description of the > > > + security events that have occurred in a security > > > + domain/model. > > > + > > > + Each entry in this file represents a single security > > > + event and consists of brace {} delimited fields that > > > + describe the characteristics of a security event. > > > + Each field has key=value pairs that define > > > + characteristics of the field. > > > + > > > + Each line in a trajectory, or forensics, file will > > > + always have the event{} and COE{} fields. The event > > > + field describes the characteristics of a security > > > + event while the COE field describes the Context Of > > > + Execution that is executing the security event. > > I think it would be good to provide a concrete definition of > > CELL_DEFINITION field as other areas of the documentation make > > reference to it within the tsem/trajectory file documentation. We can > > somewhat infer it's format, fields, etc. but it's much better to be > > explicit about these things. > > Valid point, we will incorporate a broad definition of what the 'CELL' > represents. > > Conceptually, it is equivalent to the 'object' in mandatory access > controls. In an events based architecture like TSEM, it is > essentially the 'bucket' of values that describe the parameters of a > security event that a COE/process is requesting permission for. > > The name is actually in deference to Turing theory, which all of this > relates back to, but no need to go there now. > > > > + The event{} field consists of the following > > > + characteristic definitions: > > I'm unclear as to the purpose of the event{} field as it is neither > > part of the COE or the CELL, is it here simply to make the event > > easier to read? Or am I misunderstanding things and the event{} > > field is part of the COE? > > It actually serves two roles, one of which, as you note, is to make > the event description easier to read and understand. > > It probably comes as no surprise, but the trust orchestration system > that this is all designed to support, has a security console that can > be used to review the status of all the trust orchestrators that are > supervising security workloads. Either in the cloud, or perhaps, a > large body of edge devices protecting critical infrastructure, if that > doesn't give away too much.... :-) > > Having the process name and executable easily visualized is fairly > useful. > > The second role is to allow the event description records to be > self-describing. The value for the type= key is used by the Trusted > Modeling Agent (TMA) to determine what to look for in the remainder of > the event description record in order to compute the CELL value. > > It also contains the TASK_ID value that ties the security state points > to the integrity of the executable. Since that value is a synthetic > value it was deemed most appropriate to be placed in the event{} > field. > > > > + process=COMM > > > + Where COMM is the ASCII representation > > > + of the name of the process executing > > > + the event. > > > + > > > + filename=PATH > > > + If the CELL definition for an event > > > + references a file the filename > > > + characteristic contains a definition > > > + of the path to the file. > > > + > > > + In the case where an event does not > > > + have a file the PATH value is set to a > > > + value of none. > > What happens in cases where multiple file paths are present in an > > event? Also, given this is visible to userspace, and multiple > > things can affect the path to a file (e.g. namespaces), how is the > > file path determined? > > Unless we have missed something, which is no doubt possible, all of > the security event hooks that we have implemented, which number about > 87 now, that act on a 'file', receive only a single 'struct file *' > pointer as a parameter to the event. > > So we haven't encountered a situation where there would be multiple > files for a single event description. > > There is certainly the case where multiple security state points > involve the same file. This can easily be seen, for example, in a > trust orchestrator running a workload in a runc container, where > multiple state points are generated by different executable mappings > of the runc binary at startup > > The file path is the absolute pathname in the mount namespace that the > modeled workload is running in. > > See the following for details: > > security/tsem/event.c:get_path() > > > > + type=EVENT_TYPE > > > + The value field for a type key is the > > > + name of the security event that is > > > + being modeled. The list of value > > > + EVENT_TYPE names is defined in the > > > + following source file: > > > + > > > + security/tsem/tsem.c > > > + > > > + If the security event is a generically > > > + modeled event the EVENT_TYPE will be > > > + generic_event. In this case the CELL > > > + characteristics for the event will be > > > + described by a generic_event{} field. > > > + > > > + task_id=TASK_ID > > > + The value of the task_id key will the > > > + ASCII base 16 representation of the > > > + model identity of the task that is > > > + executing the security event. > > > + > > > + The following documentation file: > > > + > > > + Documentation/admin-guide/LSM/TSEM.rst > > > + > > > + Describes how the TASK_ID value is > > > + generated. > > > + > > > + The COE{} field consists of the following > > > + characteristic definitions: > > > + > > > + uid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the discretionary > > > + user id of the process that is > > > + executing the security event. > > Given the ability to map UID/GID values in the kernel, what will be > > used as the basis for the COE? What happens when the basis used in > > the kernel's COE generation does not match the basis used by the > > external modeler? > > The UID/GID values used are the values defined in the initial > user namespace, see security/tsem/event.c:get_COE(). > > The basis set state that the trust orchestrator is running in has no > effect on the generation of the security state point. The modeling > engine only operates on the values presented to it and determines if > the state point generated from the state description matches the model > it has been requested to enforce. > > If it doesn't, the event is considered to violate the trust model. > > > > + euid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the effective > > > + discretionary user id of the process > > > + that is executing the security event. > > > + > > > + euid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the effective > > > + discretionary user id of the process > > > + that is executing the security event. > > > + > > > + suid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the saved user id > > > + of the process that is executing the > > > + security event. > > > + > > > + gid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the discretionary > > > + group id of the process that is > > > + executing the security event. > > > + > > > + egid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the discretionary > > > + effective group id of the process that > > > + is executing the security event. > > > + > > > + egid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the discretionary > > > + effective group id of the process that > > > + is executing the security event. > > > + > > > + sgid=NN > > > + The base 10 ASCII representation of > > > + the numeric value of the saved > > > + discretionary group id of the process > > > + that is executing the security event. > > > + > > > + fsuid=NN > > > + The base 10 ASCII representation of > > > + the numeric value of the discretionary > > > + filesystem user id of the process that > > > + is executing the security event. > > > + > > > + fsgid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the discretionary > > > + filesystem group id of the process > > > + that is executing the security event. > > > + > > > + cap=0xNNN > > > + The ASCII base 16 representation of > > > + the numeric value of effective > > > + capabilities of the process that is > > > + executing the security event. > > > + > > > + If the CELL value for a security event includes the > > > + definition of a file a file{} event field will be > > > + included. The following characteristics will be > > > + encoded in this field: > > > + > > > + flags=NN > > > + The ASCII base 10 representation of > > > + the flags value of the 'struct file' > > > + structure that is the source of the > > > + file description. > > > + > > > + uid=NN > > > + The ASCII base 10 representation of > > > + the discretionary user id of the file. > > > + > > > + gid=NN > > > + The base 10 ASCII representation of > > > + the discretionary group id of the > > > + file. > > Similar to the task UID/GID mapping questions above, there are > > mechanisms which map the file user/group IDs, which will be used in > > the CELL definition and how will that be resolved between the kernel > > and an external modeler? > > The answer is the same as with the COE, see the following function: > > security/tsem/event.c:get_file_cell() > > Once again, the TMA only operates on the event description presented > to it and is not influenced by its own namespace. > > > > +What: /sys/fs/tsem/ExternalTMA > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The ExternalTMA directory is a container directory > > > + that hold files that will be used to export the > > > + security events, and their associated parameters, for > > > + externally modeled security domains/namespaces. > > > + > > > + The files created in this directory will be named by > > > + the base 10 ASCII representation of the id value > > > + assigned to the modeling domain/namespace. See the > > > + documentation for the /sys/fs/tsem/id file in this > > > + documentation for more details on this value. > > > + > > > + This file will is a read-only file that can be polled > > > + by a userspace trust orchestration implementation to > > > + process security events that are to be modeled by > > > + an external Trusted Modeling Agent. > > > + > > > + The type of the exported event is the first keyword of > > > + the line that is output and have the following > > > + values and arguments: > > > + > > > + aggregate HEXID: > > > + Where HEXID is the ASCII base 16 > > > + representation of the 256 bit hardware > > > + platform aggregate value. > > > + > > > + export pid{NNN} COE{} CELL_DEFINITION > > > + Where the NNN in the pid field is the ASCII > > > + base 10 value of the id of the process that is > > > + executing the security event that will be > > > + modeled. > > I worry whenever I see a PID used as an identifier shared across the > > kernel/userspace boundary as it is inherently racy. Given the > > somewhat coarse COE definition where one can expect multiple > > processes/PIDs to share the same COE value, and the ability of > > untrusted users/processes to manipulate the PID table, what do you > > expect to use the pid{NNN} field for in this event? > > > > Similar to the other namespace/mapping issues discussed previously, > > there is also the PID namespace issue to worry about. How is that > > handled here? > > The concern over the PID issue is understandable, I will treat the > reasoning behind its use below. > > The PID value is the 'native' value managed by the kernel, not a > mapped value. > > > > + The COE field has the same format as the field > > > + emitted for a trajectory or forensics event. > > > + > > > + The CELL_DEFINITION are the same field > > > + definitions that are emitted for a trajectory > > > + or forensics event. > > > + > > > + log process{name} event{type} action{type} > > > + The log event is emitted when an untrusted > > > + task attempts to execute a security event. > > > + > > > + The name value of the COE field is the name of > > > + the process (comm value) that is executing the > > > + security event. > > > + > > > + The type value of the event field is the name > > > + of the security event being executed as > > > + defined in the tsem_names array in the > > > + security/tsem/tsem.c file. > > > + > > > + The type value of the action field is the type > > > + of action the LSM enforced in response to > > > + encountering the untrusted process. This > > > + value will be either LOG or EPERM to represent > > > + whether or not the trust violation is being > > > + logged or enforced. > > > + > > > +What: /sys/fs/tsem/control > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The control file is the only writable file in the > > > + filesystem and is used by the trust orchestrators to > > > + configure and control the behavior of the TSEM > > > + implementation. > > > + > > > + The following keyword and arguments are recognized: > > > + > > > + internal: > > > + The internal keyword causes an internally > > > + modeled domain to be created for the calling > > > + process. > > > + > > > + external: > > > + The external keyword causes an externally > > > + modeled domain to be created for the calling > > > + process. > > > + > > > + enforce: > > > + The enforce keyword causes the modeling > > > + domain/namespace of the process to enter > > > + enforcing mode. In this mode a value of > > > + -EPERM will be returned for a security event > > > + that does not map into the current set of > > > + allowed state points for the security model > > > + being implemented for the domain/namespace. > > > + > > > + seal: > > > + The seal keyword causes the security model > > > + being implemented for the model to be placed > > > + in sealed state. In this state the current > > > + set of security event points is considered to > > > + be the only set of valid points for the > > > + domain/model. Any subsequent events that map > > > + to a point not in the current model will be > > > + considered a violation of the model. > > > + > > > + trusted PID: > > > + The trusted keyword is used by a trust > > > + orchestrator to indicate that the process > > > + identified by the PID argument should be > > > + allowed to run in trusted status. > > > + > > > + untrusted PID: > > > + The untrusted keyword is used by a trust > > > + orchestrator to indicate that the process > > > + identified by the PID argument should be > > > + allowed to run but designated as an untrusted > > > + process. > > The 'trusted PID:' and 'untrusted PID:' commands are concerning for > > the reasons described above about PIDs being racy and generally an > > unreliable way of identifying processes across the kernel/userspace > > boundary. I suspect it would not be too difficult for a malicious > > user to trick an external modeler into marking the wrong process as > > trusted/untrusted. > > An external TMA needs the PID value to determine which process to wake > up and set the trust status value on in the task control structure, > after the event is modeled. As was noted above, the PID value is the > unmapped value maintained by the OS. > > Lets see if we can reason through why the PID can be used safely. > > CAP_TRUST, or whatever ends up getting used, is required by the trust > orchestrator to create a security/modeling namespace for the workload > being modeled. This results in the creation of the following > pseudo-file for surfacing the security event descriptions for the > namespace/workload: > > /sys/fs/tsem/ExternalTMA/N > > Where N is the id number of the modeling domain. > > CAP_TRUST, caveats applied, is required to open the pseudo-file. The > trust orchestrator only receives and acts on PID values through this > conduit from the kernel. > > When an event description is exported, the trust status of the task is > set to 'pending' and the process is placed in interruptible sleep and > scheduled away, with the 'wakeup' criteria being the trust status > being changed from pending to either trusted or untrusted. > > The only path to change the trust status value in the LSM task control > structure and wake up the process is by the trust orchestrator that > created the namespace, by writing the appropriate value to the > /sys/fs/tsem/control file. Access to that file is gated by CAP_TRUST > or its equivalent. > > See the following code locations for further details: > > security/tsem/export.c:tsem_export_event() > > security/tsem/fs.c:control_COE() > > As long as the process 'exists', albeit sleeping, the PID slot is > occupied and an adversary, regardless of namespace, cannot substitute > a task with the same PID value. > > This leaves an adversary with the need to terminate the task being > modeled in order to capture its PID slot. > > Precautions are implemented in the following function to protect the > process from being terminated by an adversary: > > security/tsem/tsem.c:tsem_task_kill() > > The following is a summary of the criteria that is implemented: > > - Signal privileges are granted to any process with CAP_TRUST. > > - A process without CAP_TRUST cannot signal a process with CAP_TRUST. > > - Cross-model signaling is denied by a process without CAP_TRUST. > > So that leaves us in a scenario where, outside of the modeling > namespace, CAP_TRUST would be required to kill the process waiting to > be modeled. If CAP_TRUST has been lost to an adversary, the platform > is owned and the game is over. > > So that leaves us with the threat of an adversary attempting to > implement a PID race within the modeling domain itself. > > As I've noted previously in these threads, and in the LSM > documentation proper, TSEM is about prospective generation of a > security model, rather than retrospective correction of a MAC policy > that has been demonstrated to have undesired effects. The distinction > is important in this case. > > For an adversary to mount a PID race attack from within the modeled > workload, one of three conditions must be met: > > - A shell script is read. > > - A malicious binary would have to be executed. > > - Memory would have had to have been mapped executable. > > Since TSEM captures the security events needed to implement these > actions, the events would have had to have been incorporated into the > security unit test for the workload or the actions would be denied. > > Hopefully this analysis is complete and correct with respect to this > threat, comments and observations are obviously welcome. > > There is an opportunity to strengthen this model that I will touch on > below. > > > > + state HEXID: > > > + The state keyword is used to indicate that the > > > + security state point identified by the ASCII > > > + base 16 encoded value should be loaded into > > > + the current security model as a valid security > > > + event state. > > > + > > > + pseudonym HEXID > > > + The pseudonym keyword is used to indicate that > > > + the pathname, identified by the 256 bit ASCII > > > + base 16 encoded value HEXID, should be > > > + designated to return a constant digest value > > > + for the contents of the file. > > > + > > > + The HEXID value is computed with the following > > > + function: > > > + > > > + HEXID = SHA256(PATHNAME_LENGTH || PATHNAME) > > This seems like an unusual design choice, and perhaps one born from > > necessity ... ? It's nice that it is opt-in, but I would be curious > > to hear what problems this solved. > > It is an approximation method that allows things like log files and > .bash_history files to be effectively modeled. > > Once again, TSEM is a blending of integrity measurement and mandatory > access controls. In a security event that has a file as a component > of its CELL, the SHA256 digest value of the file is included in the > computation of the CELL identity. > > These types of files have no known 'good' value, by definition. So > 'pseudonym' declarations implement a model approximation to provide a > fixed digest value for a file, regardless of its contents. > > The effect of this can easily be seen if one of the Quixote trust > orchestrators is used to run a container based shell workload. If the > .bash_history file in the container is not zeroed before execution, or > treated as a pseudonym, the bash shell will be tagged and 'poisoned' > as untrusted when it reads the file. > > It is a pretty solid understanding in modeling theory that > approximations are almost universally required when dealing with > physical phenomenon. As a quantum chemist by training, I spent a fair > amount of time dealing with complete, intermediate and modified > neglect of diatomic overlap as a result of this.... :-) > > > > + base HEXID > > > + The base keyword is used to indicate that the > > > + 256 bit ASCII base 16 encoded value HEXID > > > + should be registered as the value used to > > > + generate model specific security event points. > > > + > > > + A model specific base value is designed to be > > > + used as a 'freshness' nonce, similar to an > > > + attestation nonce, to prove that a model state > > > + value or measurement is current and not being > > > + replayed. > > > diff --git a/Documentation/admin-guide/LSM/tsem.rst b/Documentation/admin-guide/LSM/tsem.rst > > > new file mode 100644 > > > index 000000000000..f03e5269cd25 > > > --- /dev/null > > > +++ b/Documentation/admin-guide/LSM/tsem.rst > > > @@ -0,0 +1,1240 @@ > > > +==== > > > +TSEM > > > +==== > > > > ... > > > > > +Process and Platform Trust Status > > > +================================= > > > + > > > +A fundamental concept in TSEM is the notion of providing a precise > > > +definition for what it means for a platform or workload to be trusted. > > > +A trusted platform or workload is one where there has not been an > > > +attempt by a process to execute a security relevant event that does > > > +not map into a known security state point. > > > + > > > +The process trust status is a characteristic of the process that is > > > +passed to any subordinate processes that are descendants of that > > > +process. Once a process is tagged as untrusted, that characteristic > > > +cannot be removed from the process. In a 'fruit from the poisoned > > > +vine' paradigm, all subordinate processes created by an untrusted > > > +process are untrusted as well. > > > + > > > +On entry into each TSEM security event handler, the trust status of a > > > +process is checked before an attempt to model the event is made. An > > > +attempt to execute a security event by an untrusted process will cause > > > +the event, and its characteristics, to be logged. The return status > > > +of the hook will be determined by the enforcement state of the model. > > > +A permission denial is only returned if the TMA is running in > > > +enforcing mode. > > > + > > > +If the platform running the TSEM LSM has a TPM, the hardware aggregate > > > +value is computed at the time that TSEM is initialized. This hardware > > > +aggregate value is the linear extension sum over Platform > > > +Configuration Registers (PCR's) 0 through 7. This is the same > > > +aggregate value that is computed by the Integrity Measurement > > > +Architecture (IMA) and is the industry standard method of providing an > > > +evaluation measurement of the hardware platform state. > > > + > > > +Internally model domains have the hardware aggregate measurement > > > +included as the first state point in the security model. Externally > > > +modeled domains export the hardware aggregate value to the TMA for > > > +inclusion as the first state point of the model maintained by the TMA. > > > + > > > +The root modeling domain extends each security state point into PCR > > > +11. This allows hardware based TSEM measurements to coexist with IMA > > > +measurement values. This hardware measurement value can be used to > > > +attest to the security execution trajectory that the root model > > > +maintains. > > It seems like making the target PCR configurable would be a good > > idea, at the very least make it a Kconfig option. > > That was something that we have thought about, it probably needs a > Kconfig option. > > Contrary to all appearances, as a team we are really minimalists at > heart and tend to not make things more complex or configurable than > needed.... :-) > > > Also, can you elaborate on how the security state points are > > extended into the PCR? I imagine for it to be useful at an > > arbitrary point in time this would require the PCR to be extended as > > the security points were generated, which would imply that the PCR > > value would be dependent on execution order, and in most cases, > > scheduling order as well. How useful do you expect this to be for > > most users? > > Your assessment is correct, the state points are extended into the PCR > whenever a unique security state point is generated. > > In a 'free-running' model, the value in the register will be fungible > due to scheduling dependencies. > > If the model is pre-defined, the security state points will be > extended into the register as they are loaded through the > /sys/fs/tsem/map pseudo-file interface. In this case, the value will > be fixed and any departure from the value would signal that the > modeling domain has departed from its specification. > > With respect to the utility of the value, in a 'free-running' model it > is about as useful as the value that IMA maintains in PCR 10, which in > our opinion is not very useful and is why we implemented the notion of > the 'state' value of a model. > > The primary utility of the value is that it is a hardware maintained > reference value that can be used to confirm the set of measurements > committed to the register. > > So our 'state' value gives us a constant 'good' value for the security > model. The PCR 11 value provides a hardware root of trust for the set > of points that lead to the state value. > > > > +Internal vs external modeling > > > +----------------------------- > > > + > > > +When a TSEM modeling domain is created, a designation is made as to > > > +whether the domain is to be internally or externally modeled. > > > + > > > +In an internally modeled domain, the security event handlers pass the > > > +event type and its characteristics to the designated internal trusted > > > +modeling agent. The agent provides the permission value for the > > > +security event handler to return as the result of the event and sets > > > +the trust status of the process executing the event. > > > + > > > +In an externally modeled domain, the event type and parameters are > > > +exported to userspace for processing by a trust orchestrator with an > > > +associated TMA. The trust orchestrator communicates the result of the > > > +modeling back to the kernel to support the setting of the process > > > +trust status. > > > + > > > +This model poses a limitation to the ability of TSEM to model some > > > +security events. This is secondary to the fact that some event > > > +handlers (LSM hooks) are called from a non-sleeping context, as a > > > +result the process cannot be scheduled. This is particularly the case > > > +with the task based hooks, since they are typically called with the > > > +tasklist lock held. > > > + > > > +This limitation is also inherent to the root model that extends the > > > +security state points into TPM PCR 11, secondary to the fact that the > > > +process invoking the security event hook will be scheduled away while > > > +the TPM transaction completes. > > > + > > > +Addressing this problem directly requires a consideration of the > > > +context from which the security event handlers are being called. > > > +Subsequent implementations of TSEM will include a mechanism for > > > +asynchronous deferral of model processing, until when and if, a review > > > +of the call context would be considered worthwhile by the LSM > > > +community. > > This is a pretty big limitation, and in conjunction with the some of > > the other issues brought up earlier (the PID issue seems the most > > concerning), I'm having a difficult time believeing that an external > > modeler could operate safely given the design presented here. > > With respect to the PID issue, we would welcome any comments on the > analysis that we provided above as to its design safety. > > If the PID issue remains a concern, we have an extension to the export > descriptions that would include a random nonce that would be emitted > with the PID. The nonce would be placed in the LSM task control > 'blob' for the sleeping task and used to confirm that the task release > directive was acting on the correct process. > > > Unfortunately, there will always be LSM hooks which need to operate > > in a non-blocking context, meaning this challenge is here to stay. > > Help me understand how you could safely do asynchronous policy > > enforcement with an external modeler, I'm not sure it's possible. > > Electing to implement asynchronous enforcement would require further > thought. We were operating in the context of full disclosure in our > documentation and wanted to be up front about limitations and options. > > To be clear, at this time, we are not advocating for or bringing > forward an asynchronous update architecture. > > So, at this time, there is a well understood modeling limitation with > respect to the LSM hook implementations. That limitation is not > limited to external TMA's, since the event state points cannot be > extended into a TPM in a non-blocking context. > > So far we have only run into a handful of these events, almost > exclusively due to the LSM hooks being called with the tasklist lock > held. I see that Linus commented a couple of weeks ago that the > tasklist lock is our last big lock that may need to be looked at. > > With respect to the need for external modeling, as is the case with > all security designs, this is a cost/benefit decision. > > In some cases, for example SGX, using external modeling is the only > option, since executing in the context of an SGX enclave is not > possible from the kernel. Quixote/TSEM is actually one of the unsung > 'killer' applications for SGX, at least from our long involvement with > the technology. > > Having an external modeling option also means that you don't need to > get code into the kernel proper in order to implement a security model > that may be useful. I think we all can appreciate the utility and > importance of that. > > We believe that the ability to do dedicated hardware security > co-processors is important. External modeling opens the door to > democratize how that can be done. > > The binary Quixote distribution includes firmware for an > NRF52840-DONGLE implementation of a TMA. So you have a clear > demonstration of the opportunity to create 'Yubikey' type devices to > enforce kernel security. > > A reasonably interesting option for entities distributing dedicated > Linux based devices, where for a few dollars you can include a USB > based co-processor that would provide hardware based protections to > prevent an embedded Linux implementation from being diverted from its > design intent. > > Truth be told, after having looked at countless execution > trajectories, processes are typically locked into untrusted status > before they get to any of the non-blocking hooks. > > > Frankly, I also wonder how a system would perform with an external > > modeler, indepdent of the issues with non-blocking hooks. How does > > the system perform with every blockable LSM hook invocation > > potentially blocking on a response from userspace? Or with the COE > > being somewhat coarse, does the trajectory/policy populate itself > > quickly? > > One obviously experiences a latency hit in going to userspace, by > definition, implementing security always has an associated resource > cost. So, once again, this comes down to a cost/benefit analysis. > > As a Gedanken exercise, consider the value proposition of a Linux > based RTU, or other device, controlling infrastructure that can only > execute security relevant events that are guaranteed to be known good > by an external co-processor that is only accessible as a security > oracle. > > Given that frame of reference. > > Time for a userspace or SGX based TMA transaction is running around > 890 micro-seconds. > > Going to a TMA based in a Xen stubdomain implementation runs a bit > longer, probably around 940 micro-seconds or so. > > The micro-controller implementations are decidedly slower, with the > NRF52840-DONGLE clocking in at around 40 micro-seconds, but that is > strictly a CPU horsepower issue. > > All of this with the caveat that we have been focusing almost > exclusively on correctness and not optimizing performance. > > We've thought a bit, mainly on long walks with our Golden Retriever > Izzy, about the issue of building a kernel based policy cache with > externally modeled domains. Given that the kernel does not, a-priori, > know what modeling algorithm a TMA might be using, we would need to > come up with a method of deterministically mapping a security event > description to a known good state point value. > > The other issue with all this is that with containerized workloads, > particularly micro-services, the rate of security event generation can > be surprisingly low. Obviously this is also the case with embedded > implementations. > > Once again, what are you willing to pay to be safe? > > > > +Event handlers that cannot be directly modeled, still consider, on > > > +entry, whether or not they are being called by an trusted or untrusted > > > +process. As a result, an untrusted process will cause a non-modeled > > > +event to return a permissions violation in enforcing mode, even if the > > > +security event cannot be directly modeled. > > > + > > > +Security event modeling typically traps violations of trust by a COE > > > +with unmodeled characteristics that is attempting to access/execute a > > > +file or map memory as executable; or by a COE with known > > > +characteristics attempting to access or execute a CELL not prescribed > > > +by a model. As a result, the impact of the ability to not directly > > > +model these events is lessened. > > > > ... > > > > > +Event modeling > > > +-------------- > > > + > > > +TSEM security event modeling is based on the following functional > > > +definition for a security state point: > > > + > > > +Sp = SHA256(SHA256(EVENT_ID) || TASK_ID || SHA256(COE) || SHA256(CELL)) > > It appears that all of the hasing in TSEM is SHA256 based, you might > > want to consider making that a Kconfig option at the very least. > > That has been something that we have talked about as well. > > As I indicated previously, we really are minimalists, particularly > after watching IMA fight with issues surrounding algorithmic agility. > > It would be easy enough to make this configurable but does anyone see > SHA256 as not being useful in in this role anywhere in the next 10 > years? > > > paul-moore.com > > Hopefully all of this is useful moving forward. > > Have a good day. > > As always, > Dr. Greg > > The Quixote Project - Flailing at the Travails of Cybersecurity
On Tue, Feb 14, 2023 at 01:18:45PM +0100, Roberto Sassu wrote: > On Tue, 2023-02-14 at 05:58 -0600, Dr. Greg wrote: > > Our personal prejudice is that these types of measurements are of > > limited value, which is why we introduce in TSEM, the notion of the > > 'state' value for a model, discussed below. > > > > I would have to go looking on lore for a reference to the exact thread > > but Roberto Sassu had offered up a patch set for IMA that addressed > > the deficiency of these types of measurements. > Hi Greg Good morning Roberto, thank you for taking the time to follow up, pleasant to hear from you. > yes, this: > > https://lore.kernel.org/linux-integrity/20210914163401.864635-1-roberto.sassu@huawei.com/ > > DIGLIM makes the PCR extended with software measurements deterministic, > independent from how processes are scheduled, at the cost of not > knowing if files with matching digests from a list were accessed or > not, and in which order. Yes, DIGLIM, I remember the patch series you sent out but couldn't put a name to it when I wrote the reply to Paul. Our efforts and work share the same issues with respect to the indeterminism of strictly linear extension measurements, particularly now in the age of ubiquitous SMP. The 'state' value supported by the Quixote model is designed to address the same problem and has worked extremely well for us. Our implementation only sorts the security state event points that have been 'touched' by the execution trajectory, so it does provide a measurement of the events that have occurred. Like DIGLIM, you lose the the ordering of the events, but we also provide the linear sequence of security state points, and its classic measurement value, if one wants to go down the rabbit hole of figuring out if the integrity of the system has been affected by process scheduling. Frankly, I don't see the current state of the art in trusted systems being in a position to worry about that at this point in time. > But, in exchange, you can seal a TLS key to IMA measurements that is > available for handshakes as long as the system does not execute > something unknown. After that, you have to reboot to use the key > again. The same rationale for why we developed the notion of the model 'state' value. We also look at the 'state' value as a method for a containerized workload, coming out of a CI/CD development framework, to provide an attestation of a single value to indicate whether or not the workload is correct or trusted. We believe this will become increasingly important as technologies like TDX, and AMD's equivalent come forward, that will be requiring attestation as a function of the 'boot' sequence. > (Didn't read your proposal yet.) Once you get a chance to look at Quixote/TSEM and things settle down for us a a bit, we should chat about a common kernel framework for cacheing digest values as our needs are quite similar. There would seem to be no compelling reason to build separate implementations of the same technology. Our current digest cache was only driven by the mandates of simplicity and correctness. Our plans are to add the equivalent of a Bloom filter in front of a bucket of lists that key on the MSB of the digest value. If I remember correctly, you had expended efforts on optimizing your implementation. One ends up with a lot of security event state points when you boot a modern general purpose Linux administration. > Roberto Thanks again, will look forward to chatting about these issues further. Have a good remainder of the week. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity
On Tue, Feb 14, 2023 at 6:58 AM Dr. Greg <greg@enjellic.com> wrote: > On Sun, Feb 12, 2023 at 11:33:26PM -0500, Paul Moore wrote: > > On Sat, Feb 4, 2023 at 12:33 AM Dr. Greg <greg@enjellic.com> wrote: > > > > > > An entry was added to the ABI testing documentation to document > > > the files in the TSEM management filesystem. > > > > > > The file documenting the kernel command-line parameters was > > > updated to document the tsem_mode command-line parameter. > > > > > > The primary TSEM documentation file was added to the LSM > > > administration guide and the file was linked to the index of LSM > > > documentation. > > > > > > Signed-off-by: Greg Wettstein <greg@enjellic.com> > > > --- > > > Documentation/ABI/testing/tsemfs | 576 ++++++++ > > > Documentation/admin-guide/LSM/index.rst | 1 + > > > Documentation/admin-guide/LSM/tsem.rst | 1240 +++++++++++++++++ > > > .../admin-guide/kernel-parameters.txt | 5 + > > > 4 files changed, 1822 insertions(+) > > > create mode 100644 Documentation/ABI/testing/tsemfs > > > create mode 100644 Documentation/admin-guide/LSM/tsem.rst > > > One of the more important requirements for any new LSM is that it > > documents a clear, understandable, and reasonable security model along > > with an implementation that faithfully implements that model. Before > > I looked at your code I wanted to try and understand the TSEM security > > model and a few things jumped out at me rather quickly, I imagine > > there would be others as I start to look a bit closer but I wanted to > > send these questions/comments along now to get your take on them ... > > Hi Paul, thanks for taking time to review the documentation and raise > questions, responses below. > > > > diff --git a/Documentation/ABI/testing/tsemfs b/Documentation/ABI/testing/tsemfs > > > new file mode 100644 > > > index 000000000000..3d326934624c > > > --- /dev/null > > > +++ b/Documentation/ABI/testing/tsemfs ... > > > +What: /sys/fs/tsem/measurement > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The measurement file contains the ASCII base 16 > > > + hexadecimal representation of the 256 bit measurement > > > + value of the security model that the process is > > > + operating in. > > > + > > > + The measurement value is the classic linear extension > > > + measurement of the model. An updated measurement > > > + value is created by extending the current measurement > > > + value with the state coefficient computed for a > > > + security event. > > > + > > > + This measurement value represents a time dependent > > > + measurement of a model and is susceptible to > > > + deviations caused by scheduling differences between > > > + subsequent invocations of a workload. > > > Given the very volatile nature of this value, what is it used for in > > userspace? My apologies if I missed it in the docs. > > It serves the same role as PCR register 10 in IMA, or any other > register in a TPM based architecture using a classic linear extension > mechanism strategy, it can be used to validate a list of time or > sequence ordered measurement values. > > Our personal prejudice is that these types of measurements are of > limited value, which is why we introduce in TSEM, the notion of the > 'state' value for a model, discussed below. > > I would have to go looking on lore for a reference to the exact thread > but Roberto Sassu had offered up a patch set for IMA that addressed > the deficiency of these types of measurements. If we all agree that this measurement isn't very useful, and you have implemented an alternative which is intended to address these usability shortcomings, why bother including this measurement in TSEM? It's relatively easy to add features to the Linux Kernel as time goes on, it is *very* difficult to remove them. For this initial submission I would encourage you to implement the bare minimum functionality you need to do something useful and meet your goals. > > > +What: /sys/fs/tsem/points > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The points file contains the ASCII base 16 > > > + representation of the 256 bit security state points of > > > + a security domain/model. The number of entries in > > > + this file represent the number of security events that > > > + are represented by the model. > > > A similar questions to the tsem/measurement file. If I understand > > you correctly, this is basically a series of SHA256 digests without > > any additional annotations, and without any ordering guarantees, > > yes? What is it used for in userspace? > > The values in the points file represent the current state of a model, > they are the coefficients that describe the security events that have > been modeled. > > The output of this file can be captured and written to the > /sys/fs/tsem/map file in order to define a security model that is to > be subsequently enforced. Okay, I was under the assumption that this file was dependent on the order in which execution takes place on the system, it sounds like that is not the case and the output of this file is repeatable with a fairly standard system configuration (e.g. multi-core, multi-user, etc.). > > > +What: /sys/fs/tsem/state > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The state file contains the ASCII base 16 > > > + representation of the 256 bit value of the functional > > > + state of a security domain/model. > > > + > > > + The state value is a time independent representation > > > + of the measurement of a model/domain, and unlike the > > > + measurement value, is a time independent > > > + representation of the security state of a workload. > > > + > > > + This value is designed to be a single value that can > > > + be attested to represent whether or not a workload has > > > + deviated from a defined security behavior. > > > It might be nice to explain how this value is calculated here in > > this file to remove any time or ordering dependencies. Once again > > my apologies if I missed it in the rest of the docs. > > The TSEM LSM documentation covers the issues surrounding the > measurement and state values. See the section entitled 'Security > model functional definitions'. Thanks. A reference to the related section in the TSEM docs would be nice to see here. > Put succinctly, the state value is computed by generating a standard > linear extension sum over a list of security state points that have > been sorted in big-endian, ie. natural hash order. > > It is designed to provide a time and scheduling independent value that > can be used to attest that a security model has not violated its > definition. Understood. > Don't apologize, there is a lot there to read, our loquaciousness > knows no bounds.... :-) > > > > +What: /sys/fs/tsem/trajectory > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The trajectory file contains a description of the > > > + security events that have occurred in a security > > > + domain/model. > > > + > > > + Each entry in this file represents a single security > > > + event and consists of brace {} delimited fields that > > > + describe the characteristics of a security event. > > > + Each field has key=value pairs that define > > > + characteristics of the field. > > > + > > > + Each line in a trajectory, or forensics, file will > > > + always have the event{} and COE{} fields. The event > > > + field describes the characteristics of a security > > > + event while the COE field describes the Context Of > > > + Execution that is executing the security event. > > > I think it would be good to provide a concrete definition of > > CELL_DEFINITION field as other areas of the documentation make > > reference to it within the tsem/trajectory file documentation. We can > > somewhat infer it's format, fields, etc. but it's much better to be > > explicit about these things. > > Valid point, we will incorporate a broad definition of what the 'CELL' > represents. > > Conceptually, it is equivalent to the 'object' in mandatory access > controls. In an events based architecture like TSEM, it is > essentially the 'bucket' of values that describe the parameters of a > security event that a COE/process is requesting permission for. Yes, I understood conceptually what it represents and what data might be present given a specific operation/rule, but it wasn't clear to me how that data would be represented in the CELL_DEFINITION. > > > + The event{} field consists of the following > > > + characteristic definitions: > > > I'm unclear as to the purpose of the event{} field as it is neither > > part of the COE or the CELL, is it here simply to make the event > > easier to read? Or am I misunderstanding things and the event{} > > field is part of the COE? > > It actually serves two roles, one of which, as you note, is to make > the event description easier to read and understand. > > It probably comes as no surprise, but the trust orchestration system > that this is all designed to support, has a security console that can > be used to review the status of all the trust orchestrators that are > supervising security workloads. Either in the cloud, or perhaps, a > large body of edge devices protecting critical infrastructure, if that > doesn't give away too much.... :-) > > Having the process name and executable easily visualized is fairly > useful. > > The second role is to allow the event description records to be > self-describing. The value for the type= key is used by the Trusted > Modeling Agent (TMA) to determine what to look for in the remainder of > the event description record in order to compute the CELL value. > > It also contains the TASK_ID value that ties the security state points > to the integrity of the executable. Since that value is a synthetic > value it was deemed most appropriate to be placed in the event{} > field. I think it would be good to provide a more succinct version of the above in the documentation. > > > + process=COMM > > > + Where COMM is the ASCII representation > > > + of the name of the process executing > > > + the event. > > > + > > > + filename=PATH > > > + If the CELL definition for an event > > > + references a file the filename > > > + characteristic contains a definition > > > + of the path to the file. > > > + > > > + In the case where an event does not > > > + have a file the PATH value is set to a > > > + value of none. > > > What happens in cases where multiple file paths are present in an > > event? Also, given this is visible to userspace, and multiple > > things can affect the path to a file (e.g. namespaces), how is the > > file path determined? > > Unless we have missed something, which is no doubt possible, all of > the security event hooks that we have implemented, which number about > 87 now, that act on a 'file', receive only a single 'struct file *' > pointer as a parameter to the event. > > So we haven't encountered a situation where there would be multiple > files for a single event description. I haven't seriously looked at the TSEM sources yet, I'm trying to make sure that I first understand the security model while also ensuring that it is well documented and reasonable. While I can't speak to what LSM hooks TSEM implements, it seems like there are at least a few operations, rename and link come immediately to mind, which would have multiple filenames as part of the operation. How are those operations handled in TSEM, or are they outside the scope of TSEM? > There is certainly the case where multiple security state points > involve the same file. This can easily be seen, for example, in a > trust orchestrator running a workload in a runc container, where > multiple state points are generated by different executable mappings > of the runc binary at startup > > The file path is the absolute pathname in the mount namespace that the > modeled workload is running in. I think it is important to specify that the path recorded here is in the context of the mount namespace of the task generating the event. Yes, one could reasonably assume that, given the disjoint nature of mount namespaces, but with several other fields being recorded in the context of the initial namespace I think it is important to note these differences. > > > + type=EVENT_TYPE > > > + The value field for a type key is the > > > + name of the security event that is > > > + being modeled. The list of value > > > + EVENT_TYPE names is defined in the > > > + following source file: > > > + > > > + security/tsem/tsem.c > > > + > > > + If the security event is a generically > > > + modeled event the EVENT_TYPE will be > > > + generic_event. In this case the CELL > > > + characteristics for the event will be > > > + described by a generic_event{} field. > > > + > > > + task_id=TASK_ID > > > + The value of the task_id key will the > > > + ASCII base 16 representation of the > > > + model identity of the task that is > > > + executing the security event. > > > + > > > + The following documentation file: > > > + > > > + Documentation/admin-guide/LSM/TSEM.rst > > > + > > > + Describes how the TASK_ID value is > > > + generated. > > > + > > > + The COE{} field consists of the following > > > + characteristic definitions: > > > + > > > + uid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the discretionary > > > + user id of the process that is > > > + executing the security event. > > > Given the ability to map UID/GID values in the kernel, what will be > > used as the basis for the COE? What happens when the basis used in > > the kernel's COE generation does not match the basis used by the > > external modeler? > > The UID/GID values used are the values defined in the initial > user namespace, see security/tsem/event.c:get_COE(). Once again, please note that in the documents. > The basis set state that the trust orchestrator is running in has no > effect on the generation of the security state point. The modeling > engine only operates on the values presented to it and determines if > the state point generated from the state description matches the model > it has been requested to enforce. > > If it doesn't, the event is considered to violate the trust model. > > > > + euid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the effective > > > + discretionary user id of the process > > > + that is executing the security event. > > > + > > > + euid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the effective > > > + discretionary user id of the process > > > + that is executing the security event. > > > + > > > + suid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the saved user id > > > + of the process that is executing the > > > + security event. > > > + > > > + gid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the discretionary > > > + group id of the process that is > > > + executing the security event. > > > + > > > + egid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the discretionary > > > + effective group id of the process that > > > + is executing the security event. > > > + > > > + egid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the discretionary > > > + effective group id of the process that > > > + is executing the security event. > > > + > > > + sgid=NN > > > + The base 10 ASCII representation of > > > + the numeric value of the saved > > > + discretionary group id of the process > > > + that is executing the security event. > > > + > > > + fsuid=NN > > > + The base 10 ASCII representation of > > > + the numeric value of the discretionary > > > + filesystem user id of the process that > > > + is executing the security event. > > > + > > > + fsgid=NN > > > + The ASCII base 10 representation of > > > + the numeric value of the discretionary > > > + filesystem group id of the process > > > + that is executing the security event. > > > + > > > + cap=0xNNN > > > + The ASCII base 16 representation of > > > + the numeric value of effective > > > + capabilities of the process that is > > > + executing the security event. > > > + > > > + If the CELL value for a security event includes the > > > + definition of a file a file{} event field will be > > > + included. The following characteristics will be > > > + encoded in this field: > > > + > > > + flags=NN > > > + The ASCII base 10 representation of > > > + the flags value of the 'struct file' > > > + structure that is the source of the > > > + file description. > > > + > > > + uid=NN > > > + The ASCII base 10 representation of > > > + the discretionary user id of the file. > > > + > > > + gid=NN > > > + The base 10 ASCII representation of > > > + the discretionary group id of the > > > + file. > > > Similar to the task UID/GID mapping questions above, there are > > mechanisms which map the file user/group IDs, which will be used in > > the CELL definition and how will that be resolved between the kernel > > and an external modeler? > > The answer is the same as with the COE, see the following function: > > security/tsem/event.c:get_file_cell() > > Once again, the TMA only operates on the event description presented > to it and is not influenced by its own namespace. For this particular point, my concern isn't what policy the TMA implements, or what it uses as input, it's about understanding how this event information is collected. For fields which can be namespaced (I'm referring to "normal" Linux Kernel namespaces and not any TSEM namespaces), the TSEM documentation should make it clear which namespace is used as a basis for the value. > > > +What: /sys/fs/tsem/ExternalTMA > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The ExternalTMA directory is a container directory > > > + that hold files that will be used to export the > > > + security events, and their associated parameters, for > > > + externally modeled security domains/namespaces. > > > + > > > + The files created in this directory will be named by > > > + the base 10 ASCII representation of the id value > > > + assigned to the modeling domain/namespace. See the > > > + documentation for the /sys/fs/tsem/id file in this > > > + documentation for more details on this value. > > > + > > > + This file will is a read-only file that can be polled > > > + by a userspace trust orchestration implementation to > > > + process security events that are to be modeled by > > > + an external Trusted Modeling Agent. > > > + > > > + The type of the exported event is the first keyword of > > > + the line that is output and have the following > > > + values and arguments: > > > + > > > + aggregate HEXID: > > > + Where HEXID is the ASCII base 16 > > > + representation of the 256 bit hardware > > > + platform aggregate value. > > > + > > > + export pid{NNN} COE{} CELL_DEFINITION > > > + Where the NNN in the pid field is the ASCII > > > + base 10 value of the id of the process that is > > > + executing the security event that will be > > > + modeled. > > > I worry whenever I see a PID used as an identifier shared across the > > kernel/userspace boundary as it is inherently racy. Given the > > somewhat coarse COE definition where one can expect multiple > > processes/PIDs to share the same COE value, and the ability of > > untrusted users/processes to manipulate the PID table, what do you > > expect to use the pid{NNN} field for in this event? > > > > Similar to the other namespace/mapping issues discussed previously, > > there is also the PID namespace issue to worry about. How is that > > handled here? > > The concern over the PID issue is understandable, I will treat the > reasoning behind its use below. > > The PID value is the 'native' value managed by the kernel, not a > mapped value. Regardless of if the PID is rooted in the initial namespace or a different PID namespace, the issue of PIDs being inherently racy is a real problem. Can you help me understand how TSEM avoids the common pitfalls associated with using PIDs to identify processes on the system? > > > + The COE field has the same format as the field > > > + emitted for a trajectory or forensics event. > > > + > > > + The CELL_DEFINITION are the same field > > > + definitions that are emitted for a trajectory > > > + or forensics event. > > > + > > > + log process{name} event{type} action{type} > > > + The log event is emitted when an untrusted > > > + task attempts to execute a security event. > > > + > > > + The name value of the COE field is the name of > > > + the process (comm value) that is executing the > > > + security event. > > > + > > > + The type value of the event field is the name > > > + of the security event being executed as > > > + defined in the tsem_names array in the > > > + security/tsem/tsem.c file. > > > + > > > + The type value of the action field is the type > > > + of action the LSM enforced in response to > > > + encountering the untrusted process. This > > > + value will be either LOG or EPERM to represent > > > + whether or not the trust violation is being > > > + logged or enforced. > > > + > > > +What: /sys/fs/tsem/control > > > +Date: November 2022 > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > +Description: > > > + The control file is the only writable file in the > > > + filesystem and is used by the trust orchestrators to > > > + configure and control the behavior of the TSEM > > > + implementation. > > > + > > > + The following keyword and arguments are recognized: > > > + > > > + internal: > > > + The internal keyword causes an internally > > > + modeled domain to be created for the calling > > > + process. > > > + > > > + external: > > > + The external keyword causes an externally > > > + modeled domain to be created for the calling > > > + process. > > > + > > > + enforce: > > > + The enforce keyword causes the modeling > > > + domain/namespace of the process to enter > > > + enforcing mode. In this mode a value of > > > + -EPERM will be returned for a security event > > > + that does not map into the current set of > > > + allowed state points for the security model > > > + being implemented for the domain/namespace. > > > + > > > + seal: > > > + The seal keyword causes the security model > > > + being implemented for the model to be placed > > > + in sealed state. In this state the current > > > + set of security event points is considered to > > > + be the only set of valid points for the > > > + domain/model. Any subsequent events that map > > > + to a point not in the current model will be > > > + considered a violation of the model. > > > + > > > + trusted PID: > > > + The trusted keyword is used by a trust > > > + orchestrator to indicate that the process > > > + identified by the PID argument should be > > > + allowed to run in trusted status. > > > + > > > + untrusted PID: > > > + The untrusted keyword is used by a trust > > > + orchestrator to indicate that the process > > > + identified by the PID argument should be > > > + allowed to run but designated as an untrusted > > > + process. > > > The 'trusted PID:' and 'untrusted PID:' commands are concerning for > > the reasons described above about PIDs being racy and generally an > > unreliable way of identifying processes across the kernel/userspace > > boundary. I suspect it would not be too difficult for a malicious > > user to trick an external modeler into marking the wrong process as > > trusted/untrusted. > > An external TMA needs the PID value to determine which process to wake > up and set the trust status value on in the task control structure, > after the event is modeled. As was noted above, the PID value is the > unmapped value maintained by the OS. > > Lets see if we can reason through why the PID can be used safely. > > CAP_TRUST, or whatever ends up getting used, is required by the trust > orchestrator to create a security/modeling namespace for the workload > being modeled. This results in the creation of the following > pseudo-file for surfacing the security event descriptions for the > namespace/workload: > > /sys/fs/tsem/ExternalTMA/N > > Where N is the id number of the modeling domain. > > CAP_TRUST, caveats applied, is required to open the pseudo-file. The > trust orchestrator only receives and acts on PID values through this > conduit from the kernel. > > When an event description is exported, the trust status of the task is > set to 'pending' and the process is placed in interruptible sleep and > scheduled away, with the 'wakeup' criteria being the trust status > being changed from pending to either trusted or untrusted. > > The only path to change the trust status value in the LSM task control > structure and wake up the process is by the trust orchestrator that > created the namespace, by writing the appropriate value to the > /sys/fs/tsem/control file. Access to that file is gated by CAP_TRUST > or its equivalent. > > See the following code locations for further details: > > security/tsem/export.c:tsem_export_event() > > security/tsem/fs.c:control_COE() > > As long as the process 'exists', albeit sleeping, the PID slot is > occupied and an adversary, regardless of namespace, cannot substitute > a task with the same PID value. > > This leaves an adversary with the need to terminate the task being > modeled in order to capture its PID slot. > > Precautions are implemented in the following function to protect the > process from being terminated by an adversary: > > security/tsem/tsem.c:tsem_task_kill() What about the OOM killer? The security_task_kill() LSM hook only offers an access control point for one process sending another process a signal, it doesn't gate a process being killed for other reasons. The OOM killer is the first thing that comes to mind, but I'm reasonably certain there are other similar scenarios. > > > + state HEXID: > > > + The state keyword is used to indicate that the > > > + security state point identified by the ASCII > > > + base 16 encoded value should be loaded into > > > + the current security model as a valid security > > > + event state. > > > + > > > + pseudonym HEXID > > > + The pseudonym keyword is used to indicate that > > > + the pathname, identified by the 256 bit ASCII > > > + base 16 encoded value HEXID, should be > > > + designated to return a constant digest value > > > + for the contents of the file. > > > + > > > + The HEXID value is computed with the following > > > + function: > > > + > > > + HEXID = SHA256(PATHNAME_LENGTH || PATHNAME) > > > This seems like an unusual design choice, and perhaps one born from > > necessity ... ? It's nice that it is opt-in, but I would be curious > > to hear what problems this solved. > > It is an approximation method that allows things like log files and > .bash_history files to be effectively modeled. Okay, that's what I suspected, I just wanted to make sure there wasn't something else I was missing. > > > + base HEXID > > > + The base keyword is used to indicate that the > > > + 256 bit ASCII base 16 encoded value HEXID > > > + should be registered as the value used to > > > + generate model specific security event points. > > > + > > > + A model specific base value is designed to be > > > + used as a 'freshness' nonce, similar to an > > > + attestation nonce, to prove that a model state > > > + value or measurement is current and not being > > > + replayed. > > > diff --git a/Documentation/admin-guide/LSM/tsem.rst b/Documentation/admin-guide/LSM/tsem.rst > > > new file mode 100644 > > > index 000000000000..f03e5269cd25 > > > --- /dev/null > > > +++ b/Documentation/admin-guide/LSM/tsem.rst > > > @@ -0,0 +1,1240 @@ > > > +==== > > > +TSEM > > > +==== > > > > ... > > > > > +Process and Platform Trust Status > > > +================================= > > > + > > > +A fundamental concept in TSEM is the notion of providing a precise > > > +definition for what it means for a platform or workload to be trusted. > > > +A trusted platform or workload is one where there has not been an > > > +attempt by a process to execute a security relevant event that does > > > +not map into a known security state point. > > > + > > > +The process trust status is a characteristic of the process that is > > > +passed to any subordinate processes that are descendants of that > > > +process. Once a process is tagged as untrusted, that characteristic > > > +cannot be removed from the process. In a 'fruit from the poisoned > > > +vine' paradigm, all subordinate processes created by an untrusted > > > +process are untrusted as well. > > > + > > > +On entry into each TSEM security event handler, the trust status of a > > > +process is checked before an attempt to model the event is made. An > > > +attempt to execute a security event by an untrusted process will cause > > > +the event, and its characteristics, to be logged. The return status > > > +of the hook will be determined by the enforcement state of the model. > > > +A permission denial is only returned if the TMA is running in > > > +enforcing mode. > > > + > > > +If the platform running the TSEM LSM has a TPM, the hardware aggregate > > > +value is computed at the time that TSEM is initialized. This hardware > > > +aggregate value is the linear extension sum over Platform > > > +Configuration Registers (PCR's) 0 through 7. This is the same > > > +aggregate value that is computed by the Integrity Measurement > > > +Architecture (IMA) and is the industry standard method of providing an > > > +evaluation measurement of the hardware platform state. > > > + > > > +Internally model domains have the hardware aggregate measurement > > > +included as the first state point in the security model. Externally > > > +modeled domains export the hardware aggregate value to the TMA for > > > +inclusion as the first state point of the model maintained by the TMA. > > > + > > > +The root modeling domain extends each security state point into PCR > > > +11. This allows hardware based TSEM measurements to coexist with IMA > > > +measurement values. This hardware measurement value can be used to > > > +attest to the security execution trajectory that the root model > > > +maintains. > > > It seems like making the target PCR configurable would be a good > > idea, at the very least make it a Kconfig option. > > That was something that we have thought about, it probably needs a > Kconfig option. > > Contrary to all appearances, as a team we are really minimalists at > heart and tend to not make things more complex or configurable than > needed.... :-) > > > Also, can you elaborate on how the security state points are > > extended into the PCR? I imagine for it to be useful at an > > arbitrary point in time this would require the PCR to be extended as > > the security points were generated, which would imply that the PCR > > value would be dependent on execution order, and in most cases, > > scheduling order as well. How useful do you expect this to be for > > most users? > > Your assessment is correct, the state points are extended into the PCR > whenever a unique security state point is generated. > > In a 'free-running' model, the value in the register will be fungible > due to scheduling dependencies. In other words, garbage ;) > If the model is pre-defined, the security state points will be > extended into the register as they are loaded through the > /sys/fs/tsem/map pseudo-file interface. In this case, the value will > be fixed and any departure from the value would signal that the > modeling domain has departed from its specification. > > With respect to the utility of the value, in a 'free-running' model it > is about as useful as the value that IMA maintains in PCR 10, which in > our opinion is not very useful and is why we implemented the notion of > the 'state' value of a model. For a variety of reasons, and mostly to help keep things civil, let's refrain from comparing one LSM to another. Each LSM makes its own choices, and needs to stand on its own; just because LSM did X doesn't mean TSEM can do X if it is silly in the context of TSEM. > The primary utility of the value is that it is a hardware maintained > reference value that can be used to confirm the set of measurements > committed to the register. Given that the PCR value is only deterministic in the case of a predefined policy/model, it seems like it would be worth stating that a bit more clearly in the docs. > So our 'state' value gives us a constant 'good' value for the security > model. The PCR 11 value provides a hardware root of trust for the set > of points that lead to the state value. Just to make sure I understand you, in the predefined case PCR 11 is extended with the SRTM PCRs as well as a measurement of the TSEM policy at load time, yes? > > > +Internal vs external modeling > > > +----------------------------- > > > + > > > +When a TSEM modeling domain is created, a designation is made as to > > > +whether the domain is to be internally or externally modeled. > > > + > > > +In an internally modeled domain, the security event handlers pass the > > > +event type and its characteristics to the designated internal trusted > > > +modeling agent. The agent provides the permission value for the > > > +security event handler to return as the result of the event and sets > > > +the trust status of the process executing the event. > > > + > > > +In an externally modeled domain, the event type and parameters are > > > +exported to userspace for processing by a trust orchestrator with an > > > +associated TMA. The trust orchestrator communicates the result of the > > > +modeling back to the kernel to support the setting of the process > > > +trust status. > > > + > > > +This model poses a limitation to the ability of TSEM to model some > > > +security events. This is secondary to the fact that some event > > > +handlers (LSM hooks) are called from a non-sleeping context, as a > > > +result the process cannot be scheduled. This is particularly the case > > > +with the task based hooks, since they are typically called with the > > > +tasklist lock held. > > > + > > > +This limitation is also inherent to the root model that extends the > > > +security state points into TPM PCR 11, secondary to the fact that the > > > +process invoking the security event hook will be scheduled away while > > > +the TPM transaction completes. > > > + > > > +Addressing this problem directly requires a consideration of the > > > +context from which the security event handlers are being called. > > > +Subsequent implementations of TSEM will include a mechanism for > > > +asynchronous deferral of model processing, until when and if, a review > > > +of the call context would be considered worthwhile by the LSM > > > +community. > > > This is a pretty big limitation, and in conjunction with the some of > > the other issues brought up earlier (the PID issue seems the most > > concerning), I'm having a difficult time believeing that an external > > modeler could operate safely given the design presented here. > > With respect to the PID issue, we would welcome any comments on the > analysis that we provided above as to its design safety. From what I can tell from the documentation and our discussion thus far is that TSEM relies on a security_task_kill() hook implementation to ensure that a process is not killed, and the PID released, without explicit TSEM approval. Unfortunately, I believe that relying solely on security_task_kill() will not fully cover all of the cases where a process can be killed, mostly because security_task_kill() does not control process destruction, it controls the ability of one process to signal another. You might be able to do something with security_task_free(), but I haven't given that much thought. > If the PID issue remains a concern, we have an extension to the export > descriptions that would include a random nonce that would be emitted > with the PID. The nonce would be placed in the LSM task control > 'blob' for the sleeping task and used to confirm that the task release > directive was acting on the correct process. That should help, but ultimately a nonce is still a bounded resource and subject to recycling just like the PID. I'm open to hearing other ways in which you believe you can resolve this issue, but I remain skeptical. > > Unfortunately, there will always be LSM hooks which need to operate > > in a non-blocking context, meaning this challenge is here to stay. > > Help me understand how you could safely do asynchronous policy > > enforcement with an external modeler, I'm not sure it's possible. > > Electing to implement asynchronous enforcement would require further > thought. We were operating in the context of full disclosure in our > documentation and wanted to be up front about limitations and options. > > To be clear, at this time, we are not advocating for or bringing > forward an asynchronous update architecture. > > So, at this time, there is a well understood modeling limitation with > respect to the LSM hook implementations. That limitation is not > limited to external TMA's, since the event state points cannot be > extended into a TPM in a non-blocking context. I think these limitations need to be made explicit in the documentation. If the TSEM security model can not be faithfully implemented, the documented security model may need to change. > > Frankly, I also wonder how a system would perform with an external > > modeler, indepdent of the issues with non-blocking hooks. How does > > the system perform with every blockable LSM hook invocation > > potentially blocking on a response from userspace? Or with the COE > > being somewhat coarse, does the trajectory/policy populate itself > > quickly? > > One obviously experiences a latency hit in going to userspace, by > definition, implementing security always has an associated resource > cost. So, once again, this comes down to a cost/benefit analysis. > > As a Gedanken exercise, consider the value proposition of a Linux > based RTU, or other device, controlling infrastructure that can only > execute security relevant events that are guaranteed to be known good > by an external co-processor that is only accessible as a security > oracle. > > Given that frame of reference. > > Time for a userspace or SGX based TMA transaction is running around > 890 micro-seconds. > > Going to a TMA based in a Xen stubdomain implementation runs a bit > longer, probably around 940 micro-seconds or so. > > The micro-controller implementations are decidedly slower, with the > NRF52840-DONGLE clocking in at around 40 micro-seconds, but that is > strictly a CPU horsepower issue. > > All of this with the caveat that we have been focusing almost > exclusively on correctness and not optimizing performance. > > We've thought a bit, mainly on long walks with our Golden Retriever > Izzy, about the issue of building a kernel based policy cache with > externally modeled domains. Given that the kernel does not, a-priori, > know what modeling algorithm a TMA might be using, we would need to > come up with a method of deterministically mapping a security event > description to a known good state point value. > > The other issue with all this is that with containerized workloads, > particularly micro-services, the rate of security event generation can > be surprisingly low. Obviously this is also the case with embedded > implementations. > > Once again, what are you willing to pay to be safe? For better or worse, when code is proposed for the upstream Linux Kernel it is subject to scrutiny from all manner of developers and users, with most being focused on their own pet projects/subsystems, not whatever new security promises you are providing. There have been patch(sets) and discussions relating to performance gains/losses on the other of tens of nanoseconds per operation. I think most of us in the security community are sympathetic to the question of "what are you willing to pay to be safe", but please understand that while we are understanding, there are others who will disagree not only with the performance cost tradeoff, but the very idea of safety you are promising. My only suggestion is to be prepared, and be honest with the performance assessments of TSEM. > > > +Event handlers that cannot be directly modeled, still consider, on > > > +entry, whether or not they are being called by an trusted or untrusted > > > +process. As a result, an untrusted process will cause a non-modeled > > > +event to return a permissions violation in enforcing mode, even if the > > > +security event cannot be directly modeled. > > > + > > > +Security event modeling typically traps violations of trust by a COE > > > +with unmodeled characteristics that is attempting to access/execute a > > > +file or map memory as executable; or by a COE with known > > > +characteristics attempting to access or execute a CELL not prescribed > > > +by a model. As a result, the impact of the ability to not directly > > > +model these events is lessened. > > > > ... > > > > > +Event modeling > > > +-------------- > > > + > > > +TSEM security event modeling is based on the following functional > > > +definition for a security state point: > > > + > > > +Sp = SHA256(SHA256(EVENT_ID) || TASK_ID || SHA256(COE) || SHA256(CELL)) > > > It appears that all of the hasing in TSEM is SHA256 based, you might > > want to consider making that a Kconfig option at the very least. > > That has been something that we have talked about as well. > > As I indicated previously, we really are minimalists, particularly > after watching IMA fight with issues surrounding algorithmic agility. > > It would be easy enough to make this configurable but does anyone see > SHA256 as not being useful in in this role anywhere in the next 10 > years? There are any number of reasons why one might need to select a different hash algorithm: legal constraints, security certifications, corporate policy. I would strongly suggest making this configurable.
On Thu, Mar 02, 2023 at 11:15:56PM -0500, Paul Moore wrote: Hi Paul, thanks for sending along further comments. You note below that you haven't had time to look at the code since you wanted to confirm the TSEM security model before moving forward. From a development perspective we are now three weeks into what will become version 2 of the patch series. So at this point I wouldn't advocate spending a lot of time on the current patchset. That being said, if you some have time, we would appreciate a quick look at the code on your part, with respect to style changes and the like we can enforce in the second series, ie. ordering of local variable declarations by length and the like. Everything has to, and does, pass checkpatch but I don't believe that utility judgement on issues such as ordering of variable declarations and the like. That being said, specific comments follow below on issues you raised. > On Tue, Feb 14, 2023 at 6:58???AM Dr. Greg <greg@enjellic.com> wrote: > > On Sun, Feb 12, 2023 at 11:33:26PM -0500, Paul Moore wrote: > > > On Sat, Feb 4, 2023 at 12:33 AM Dr. Greg <greg@enjellic.com> wrote: > > > > > > > > An entry was added to the ABI testing documentation to document > > > > the files in the TSEM management filesystem. > > > > > > > > The file documenting the kernel command-line parameters was > > > > updated to document the tsem_mode command-line parameter. > > > > > > > > The primary TSEM documentation file was added to the LSM > > > > administration guide and the file was linked to the index of LSM > > > > documentation. > > > > > > > > Signed-off-by: Greg Wettstein <greg@enjellic.com> > > > > --- > > > > Documentation/ABI/testing/tsemfs | 576 ++++++++ > > > > Documentation/admin-guide/LSM/index.rst | 1 + > > > > Documentation/admin-guide/LSM/tsem.rst | 1240 +++++++++++++++++ > > > > .../admin-guide/kernel-parameters.txt | 5 + > > > > 4 files changed, 1822 insertions(+) > > > > create mode 100644 Documentation/ABI/testing/tsemfs > > > > create mode 100644 Documentation/admin-guide/LSM/tsem.rst > > > > > One of the more important requirements for any new LSM is that it > > > documents a clear, understandable, and reasonable security model along > > > with an implementation that faithfully implements that model. Before > > > I looked at your code I wanted to try and understand the TSEM security > > > model and a few things jumped out at me rather quickly, I imagine > > > there would be others as I start to look a bit closer but I wanted to > > > send these questions/comments along now to get your take on them ... > > > > Hi Paul, thanks for taking time to review the documentation and raise > > questions, responses below. > > > > > > diff --git a/Documentation/ABI/testing/tsemfs b/Documentation/ABI/testing/tsemfs > > > > new file mode 100644 > > > > index 000000000000..3d326934624c > > > > --- /dev/null > > > > +++ b/Documentation/ABI/testing/tsemfs > > ... > > > > > +What: /sys/fs/tsem/measurement > > > > +Date: November 2022 > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > +Description: > > > > + The measurement file contains the ASCII base 16 > > > > + hexadecimal representation of the 256 bit measurement > > > > + value of the security model that the process is > > > > + operating in. > > > > + > > > > + The measurement value is the classic linear extension > > > > + measurement of the model. An updated measurement > > > > + value is created by extending the current measurement > > > > + value with the state coefficient computed for a > > > > + security event. > > > > + > > > > + This measurement value represents a time dependent > > > > + measurement of a model and is susceptible to > > > > + deviations caused by scheduling differences between > > > > + subsequent invocations of a workload. > > > > > Given the very volatile nature of this value, what is it used for in > > > userspace? My apologies if I missed it in the docs. > > > > It serves the same role as PCR register 10 in IMA, or any other > > register in a TPM based architecture using a classic linear extension > > mechanism strategy, it can be used to validate a list of time or > > sequence ordered measurement values. > > > > Our personal prejudice is that these types of measurements are of > > limited value, which is why we introduce in TSEM, the notion of the > > 'state' value for a model, discussed below. > > > > I would have to go looking on lore for a reference to the exact thread > > but Roberto Sassu had offered up a patch set for IMA that addressed > > the deficiency of these types of measurements. > If we all agree that this measurement isn't very useful, and you > have implemented an alternative which is intended to address these > usability shortcomings, why bother including this measurement in > TSEM? To provide comparable functionality to TPM based security architectures, that are currently, considered state of the art for the security industry. As our documentation calls out, TSEM's concept of Trusted Modeling Agent's (TMA's), are being proposed to both explore and implement next generation hardware assisted security technologies. Currently, the only measurements that TPM based systems support are classic linear extension summing, which I believe we all consider to be problematic. That being said, the 'measurement' value can be used to validate the order of the security event execution trajectory. In that role it provides the same value that PCR register 10 plays for IMA. We believe there is a legitimate discussion that can occur, as to whether or not this classic attestation architecture is relevant, but it seemed appropriate to support it. > It's relatively easy to add features to the Linux Kernel as time > goes on, it is *very* difficult to remove them. For this initial > submission I would encourage you to implement the bare minimum > functionality you need to do something useful and meet your goals. We can certainly pull the export of the measurement value. In that case, would you recommend that we also pull the code that extends the security coefficients from the root modeling domain, if a TPM is available, into PCR register 11? > > > > +What: /sys/fs/tsem/points > > > > +Date: November 2022 > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > +Description: > > > > + The points file contains the ASCII base 16 > > > > + representation of the 256 bit security state points of > > > > + a security domain/model. The number of entries in > > > > + this file represent the number of security events that > > > > + are represented by the model. > > > > > A similar questions to the tsem/measurement file. If I understand > > > you correctly, this is basically a series of SHA256 digests without > > > any additional annotations, and without any ordering guarantees, > > > yes? What is it used for in userspace? > > > > The values in the points file represent the current state of a model, > > they are the coefficients that describe the security events that have > > been modeled. > > > > The output of this file can be captured and written to the > > /sys/fs/tsem/map file in order to define a security model that is to > > be subsequently enforced. > Okay, I was under the assumption that this file was dependent on the > order in which execution takes place on the system, it sounds like > that is not the case and the output of this file is repeatable with > a fairly standard system configuration (e.g. multi-core, multi-user, > etc.). Correct. It represents the set of allowed coefficients in the description of the functional security state of a workload. > > > > +What: /sys/fs/tsem/state > > > > +Date: November 2022 > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > +Description: > > > > + The state file contains the ASCII base 16 > > > > + representation of the 256 bit value of the functional > > > > + state of a security domain/model. > > > > + > > > > + The state value is a time independent representation > > > > + of the measurement of a model/domain, and unlike the > > > > + measurement value, is a time independent > > > > + representation of the security state of a workload. > > > > + > > > > + This value is designed to be a single value that can > > > > + be attested to represent whether or not a workload has > > > > + deviated from a defined security behavior. > > > > > It might be nice to explain how this value is calculated here in > > > this file to remove any time or ordering dependencies. Once again > > > my apologies if I missed it in the rest of the docs. > > > > The TSEM LSM documentation covers the issues surrounding the > > measurement and state values. See the section entitled 'Security > > model functional definitions'. > Thanks. A reference to the related section in the TSEM docs would > be nice to see here. We will add it. > > Put succinctly, the state value is computed by generating a standard > > linear extension sum over a list of security state points that have > > been sorted in big-endian, ie. natural hash order. > > > > It is designed to provide a time and scheduling independent value that > > can be used to attest that a security model has not violated its > > definition. > > Understood. > > > Don't apologize, there is a lot there to read, our loquaciousness > > knows no bounds.... :-) > > > > > > +What: /sys/fs/tsem/trajectory > > > > +Date: November 2022 > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > +Description: > > > > + The trajectory file contains a description of the > > > > + security events that have occurred in a security > > > > + domain/model. > > > > + > > > > + Each entry in this file represents a single security > > > > + event and consists of brace {} delimited fields that > > > > + describe the characteristics of a security event. > > > > + Each field has key=value pairs that define > > > > + characteristics of the field. > > > > + > > > > + Each line in a trajectory, or forensics, file will > > > > + always have the event{} and COE{} fields. The event > > > > + field describes the characteristics of a security > > > > + event while the COE field describes the Context Of > > > > + Execution that is executing the security event. > > > > > I think it would be good to provide a concrete definition of > > > CELL_DEFINITION field as other areas of the documentation make > > > reference to it within the tsem/trajectory file documentation. We can > > > somewhat infer it's format, fields, etc. but it's much better to be > > > explicit about these things. > > > > Valid point, we will incorporate a broad definition of what the 'CELL' > > represents. > > > > Conceptually, it is equivalent to the 'object' in mandatory access > > controls. In an events based architecture like TSEM, it is > > essentially the 'bucket' of values that describe the parameters of a > > security event that a COE/process is requesting permission for. > Yes, I understood conceptually what it represents and what data > might be present given a specific operation/rule, but it wasn't > clear to me how that data would be represented in the > CELL_DEFINITION. As a bit of further clarification, regarding the security model that TSEM is based on. A TMA extracts the event description parameters, now encoded in JSON.. :-), into a structure and then computes a digest value, referred to as the 'CELL identity value', over those elements, in whatever order the TMA elects to do so in. Further, a TMA implementation may elect to only include certain characteristics in the computation of the CELL identity, depending on the model being implemented. > > > > + The event{} field consists of the following > > > > + characteristic definitions: > > > > > I'm unclear as to the purpose of the event{} field as it is neither > > > part of the COE or the CELL, is it here simply to make the event > > > easier to read? Or am I misunderstanding things and the event{} > > > field is part of the COE? > > > > It actually serves two roles, one of which, as you note, is to make > > the event description easier to read and understand. > > > > It probably comes as no surprise, but the trust orchestration system > > that this is all designed to support, has a security console that can > > be used to review the status of all the trust orchestrators that are > > supervising security workloads. Either in the cloud, or perhaps, a > > large body of edge devices protecting critical infrastructure, if that > > doesn't give away too much.... :-) > > > > Having the process name and executable easily visualized is fairly > > useful. > > > > The second role is to allow the event description records to be > > self-describing. The value for the type= key is used by the Trusted > > Modeling Agent (TMA) to determine what to look for in the remainder of > > the event description record in order to compute the CELL value. > > > > It also contains the TASK_ID value that ties the security state points > > to the integrity of the executable. Since that value is a synthetic > > value it was deemed most appropriate to be placed in the event{} > > field. > I think it would be good to provide a more succinct version of the > above in the documentation. We will clarify that. > > > > + process=COMM > > > > + Where COMM is the ASCII representation > > > > + of the name of the process executing > > > > + the event. > > > > + > > > > + filename=PATH > > > > + If the CELL definition for an event > > > > + references a file the filename > > > > + characteristic contains a definition > > > > + of the path to the file. > > > > + > > > > + In the case where an event does not > > > > + have a file the PATH value is set to a > > > > + value of none. > > > > > What happens in cases where multiple file paths are present in an > > > event? Also, given this is visible to userspace, and multiple > > > things can affect the path to a file (e.g. namespaces), how is the > > > file path determined? > > > > Unless we have missed something, which is no doubt possible, all of > > the security event hooks that we have implemented, which number about > > 87 now, that act on a 'file', receive only a single 'struct file *' > > pointer as a parameter to the event. > > > > So we haven't encountered a situation where there would be multiple > > files for a single event description. > I haven't seriously looked at the TSEM sources yet, I'm trying to > make sure that I first understand the security model while also > ensuring that it is well documented and reasonable. While I can't > speak to what LSM hooks TSEM implements, it seems like there are at > least a few operations, rename and link come immediately to mind, > which would have multiple filenames as part of the operation. How > are those operations handled in TSEM, or are they outside the scope > of TSEM? We are currently handling them as generically modeled events so the current model treats them as whether or not they occurred. When they get promoted to explicitly modeled events, the current presumption would be to include the involved filenames in the description of the event. > > There is certainly the case where multiple security state points > > involve the same file. This can easily be seen, for example, in a > > trust orchestrator running a workload in a runc container, where > > multiple state points are generated by different executable mappings > > of the runc binary at startup > > > > The file path is the absolute pathname in the mount namespace that the > > modeled workload is running in. > I think it is important to specify that the path recorded here is in > the context of the mount namespace of the task generating the event. > Yes, one could reasonably assume that, given the disjoint nature of > mount namespaces, but with several other fields being recorded in > the context of the initial namespace I think it is important to note > these differences. We will clarify that. > > > > + type=EVENT_TYPE > > > > + The value field for a type key is the > > > > + name of the security event that is > > > > + being modeled. The list of value > > > > + EVENT_TYPE names is defined in the > > > > + following source file: > > > > + > > > > + security/tsem/tsem.c > > > > + > > > > + If the security event is a generically > > > > + modeled event the EVENT_TYPE will be > > > > + generic_event. In this case the CELL > > > > + characteristics for the event will be > > > > + described by a generic_event{} field. > > > > + > > > > + task_id=TASK_ID > > > > + The value of the task_id key will the > > > > + ASCII base 16 representation of the > > > > + model identity of the task that is > > > > + executing the security event. > > > > + > > > > + The following documentation file: > > > > + > > > > + Documentation/admin-guide/LSM/TSEM.rst > > > > + > > > > + Describes how the TASK_ID value is > > > > + generated. > > > > + > > > > + The COE{} field consists of the following > > > > + characteristic definitions: > > > > + > > > > + uid=NN > > > > + The ASCII base 10 representation of > > > > + the numeric value of the discretionary > > > > + user id of the process that is > > > > + executing the security event. > > > > > Given the ability to map UID/GID values in the kernel, what will be > > > used as the basis for the COE? What happens when the basis used in > > > the kernel's COE generation does not match the basis used by the > > > external modeler? > > > > The UID/GID values used are the values defined in the initial > > user namespace, see security/tsem/event.c:get_COE(). > Once again, please note that in the documents. Noted. > > The basis set state that the trust orchestrator is running in has no > > effect on the generation of the security state point. The modeling > > engine only operates on the values presented to it and determines if > > the state point generated from the state description matches the model > > it has been requested to enforce. > > > > If it doesn't, the event is considered to violate the trust model. > > > > > > + euid=NN > > > > + The ASCII base 10 representation of > > > > + the numeric value of the effective > > > > + discretionary user id of the process > > > > + that is executing the security event. > > > > + > > > > + euid=NN > > > > + The ASCII base 10 representation of > > > > + the numeric value of the effective > > > > + discretionary user id of the process > > > > + that is executing the security event. > > > > + > > > > + suid=NN > > > > + The ASCII base 10 representation of > > > > + the numeric value of the saved user id > > > > + of the process that is executing the > > > > + security event. > > > > + > > > > + gid=NN > > > > + The ASCII base 10 representation of > > > > + the numeric value of the discretionary > > > > + group id of the process that is > > > > + executing the security event. > > > > + > > > > + egid=NN > > > > + The ASCII base 10 representation of > > > > + the numeric value of the discretionary > > > > + effective group id of the process that > > > > + is executing the security event. > > > > + > > > > + egid=NN > > > > + The ASCII base 10 representation of > > > > + the numeric value of the discretionary > > > > + effective group id of the process that > > > > + is executing the security event. > > > > + > > > > + sgid=NN > > > > + The base 10 ASCII representation of > > > > + the numeric value of the saved > > > > + discretionary group id of the process > > > > + that is executing the security event. > > > > + > > > > + fsuid=NN > > > > + The base 10 ASCII representation of > > > > + the numeric value of the discretionary > > > > + filesystem user id of the process that > > > > + is executing the security event. > > > > + > > > > + fsgid=NN > > > > + The ASCII base 10 representation of > > > > + the numeric value of the discretionary > > > > + filesystem group id of the process > > > > + that is executing the security event. > > > > + > > > > + cap=0xNNN > > > > + The ASCII base 16 representation of > > > > + the numeric value of effective > > > > + capabilities of the process that is > > > > + executing the security event. > > > > + > > > > + If the CELL value for a security event includes the > > > > + definition of a file a file{} event field will be > > > > + included. The following characteristics will be > > > > + encoded in this field: > > > > + > > > > + flags=NN > > > > + The ASCII base 10 representation of > > > > + the flags value of the 'struct file' > > > > + structure that is the source of the > > > > + file description. > > > > + > > > > + uid=NN > > > > + The ASCII base 10 representation of > > > > + the discretionary user id of the file. > > > > + > > > > + gid=NN > > > > + The base 10 ASCII representation of > > > > + the discretionary group id of the > > > > + file. > > > > > Similar to the task UID/GID mapping questions above, there are > > > mechanisms which map the file user/group IDs, which will be used in > > > the CELL definition and how will that be resolved between the kernel > > > and an external modeler? > > > > The answer is the same as with the COE, see the following function: > > > > security/tsem/event.c:get_file_cell() > > > > Once again, the TMA only operates on the event description presented > > to it and is not influenced by its own namespace. > For this particular point, my concern isn't what policy the TMA > implements, or what it uses as input, it's about understanding how > this event information is collected. For fields which can be > namespaced (I'm referring to "normal" Linux Kernel namespaces and > not any TSEM namespaces), the TSEM documentation should make it > clear which namespace is used as a basis for the value. FWIW, based on feedback we have received, there may be a modeling domain/namspace setup option forthcoming that allows a trust orchestrator to request that the uid/gid et.al characteristics be exported in the context of the current user namespace. > > > > +What: /sys/fs/tsem/ExternalTMA > > > > +Date: November 2022 > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > +Description: > > > > + The ExternalTMA directory is a container directory > > > > + that hold files that will be used to export the > > > > + security events, and their associated parameters, for > > > > + externally modeled security domains/namespaces. > > > > + > > > > + The files created in this directory will be named by > > > > + the base 10 ASCII representation of the id value > > > > + assigned to the modeling domain/namespace. See the > > > > + documentation for the /sys/fs/tsem/id file in this > > > > + documentation for more details on this value. > > > > + > > > > + This file will is a read-only file that can be polled > > > > + by a userspace trust orchestration implementation to > > > > + process security events that are to be modeled by > > > > + an external Trusted Modeling Agent. > > > > + > > > > + The type of the exported event is the first keyword of > > > > + the line that is output and have the following > > > > + values and arguments: > > > > + > > > > + aggregate HEXID: > > > > + Where HEXID is the ASCII base 16 > > > > + representation of the 256 bit hardware > > > > + platform aggregate value. > > > > + > > > > + export pid{NNN} COE{} CELL_DEFINITION > > > > + Where the NNN in the pid field is the ASCII > > > > + base 10 value of the id of the process that is > > > > + executing the security event that will be > > > > + modeled. > > > > > I worry whenever I see a PID used as an identifier shared across the > > > kernel/userspace boundary as it is inherently racy. Given the > > > somewhat coarse COE definition where one can expect multiple > > > processes/PIDs to share the same COE value, and the ability of > > > untrusted users/processes to manipulate the PID table, what do you > > > expect to use the pid{NNN} field for in this event? > > > > > > Similar to the other namespace/mapping issues discussed previously, > > > there is also the PID namespace issue to worry about. How is that > > > handled here? > > > > The concern over the PID issue is understandable, I will treat the > > reasoning behind its use below. > > > > The PID value is the 'native' value managed by the kernel, not a > > mapped value. > Regardless of if the PID is rooted in the initial namespace or a > different PID namespace, the issue of PIDs being inherently racy is > a real problem. Can you help me understand how TSEM avoids the > common pitfalls associated with using PIDs to identify processes on > the system? The second version of the TSEM series, now includes support for a requirement that a process being externally modeled, authenticate itself to the TMA in order for the trust control call to act on the process. > > > > + The COE field has the same format as the field > > > > + emitted for a trajectory or forensics event. > > > > + > > > > + The CELL_DEFINITION are the same field > > > > + definitions that are emitted for a trajectory > > > > + or forensics event. > > > > + > > > > + log process{name} event{type} action{type} > > > > + The log event is emitted when an untrusted > > > > + task attempts to execute a security event. > > > > + > > > > + The name value of the COE field is the name of > > > > + the process (comm value) that is executing the > > > > + security event. > > > > + > > > > + The type value of the event field is the name > > > > + of the security event being executed as > > > > + defined in the tsem_names array in the > > > > + security/tsem/tsem.c file. > > > > + > > > > + The type value of the action field is the type > > > > + of action the LSM enforced in response to > > > > + encountering the untrusted process. This > > > > + value will be either LOG or EPERM to represent > > > > + whether or not the trust violation is being > > > > + logged or enforced. > > > > + > > > > +What: /sys/fs/tsem/control > > > > +Date: November 2022 > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > +Description: > > > > + The control file is the only writable file in the > > > > + filesystem and is used by the trust orchestrators to > > > > + configure and control the behavior of the TSEM > > > > + implementation. > > > > + > > > > + The following keyword and arguments are recognized: > > > > + > > > > + internal: > > > > + The internal keyword causes an internally > > > > + modeled domain to be created for the calling > > > > + process. > > > > + > > > > + external: > > > > + The external keyword causes an externally > > > > + modeled domain to be created for the calling > > > > + process. > > > > + > > > > + enforce: > > > > + The enforce keyword causes the modeling > > > > + domain/namespace of the process to enter > > > > + enforcing mode. In this mode a value of > > > > + -EPERM will be returned for a security event > > > > + that does not map into the current set of > > > > + allowed state points for the security model > > > > + being implemented for the domain/namespace. > > > > + > > > > + seal: > > > > + The seal keyword causes the security model > > > > + being implemented for the model to be placed > > > > + in sealed state. In this state the current > > > > + set of security event points is considered to > > > > + be the only set of valid points for the > > > > + domain/model. Any subsequent events that map > > > > + to a point not in the current model will be > > > > + considered a violation of the model. > > > > + > > > > + trusted PID: > > > > + The trusted keyword is used by a trust > > > > + orchestrator to indicate that the process > > > > + identified by the PID argument should be > > > > + allowed to run in trusted status. > > > > + > > > > + untrusted PID: > > > > + The untrusted keyword is used by a trust > > > > + orchestrator to indicate that the process > > > > + identified by the PID argument should be > > > > + allowed to run but designated as an untrusted > > > > + process. > > > > > The 'trusted PID:' and 'untrusted PID:' commands are concerning for > > > the reasons described above about PIDs being racy and generally an > > > unreliable way of identifying processes across the kernel/userspace > > > boundary. I suspect it would not be too difficult for a malicious > > > user to trick an external modeler into marking the wrong process as > > > trusted/untrusted. > > > > An external TMA needs the PID value to determine which process to wake > > up and set the trust status value on in the task control structure, > > after the event is modeled. As was noted above, the PID value is the > > unmapped value maintained by the OS. > > > > Lets see if we can reason through why the PID can be used safely. > > > > CAP_TRUST, or whatever ends up getting used, is required by the trust > > orchestrator to create a security/modeling namespace for the workload > > being modeled. This results in the creation of the following > > pseudo-file for surfacing the security event descriptions for the > > namespace/workload: > > > > /sys/fs/tsem/ExternalTMA/N > > > > Where N is the id number of the modeling domain. > > > > CAP_TRUST, caveats applied, is required to open the pseudo-file. The > > trust orchestrator only receives and acts on PID values through this > > conduit from the kernel. > > > > When an event description is exported, the trust status of the task is > > set to 'pending' and the process is placed in interruptible sleep and > > scheduled away, with the 'wakeup' criteria being the trust status > > being changed from pending to either trusted or untrusted. > > > > The only path to change the trust status value in the LSM task control > > structure and wake up the process is by the trust orchestrator that > > created the namespace, by writing the appropriate value to the > > /sys/fs/tsem/control file. Access to that file is gated by CAP_TRUST > > or its equivalent. > > > > See the following code locations for further details: > > > > security/tsem/export.c:tsem_export_event() > > > > security/tsem/fs.c:control_COE() > > > > As long as the process 'exists', albeit sleeping, the PID slot is > > occupied and an adversary, regardless of namespace, cannot substitute > > a task with the same PID value. > > > > This leaves an adversary with the need to terminate the task being > > modeled in order to capture its PID slot. > > > > Precautions are implemented in the following function to protect the > > process from being terminated by an adversary: > > > > security/tsem/tsem.c:tsem_task_kill() > What about the OOM killer? > > The security_task_kill() LSM hook only offers an access control point > for one process sending another process a signal, it doesn't gate a > process being killed for other reasons. The OOM killer is the first > thing that comes to mind, but I'm reasonably certain there are other > similar scenarios. As noted above, as an additional protection, the next version of the series requires that a process authenticate itself as being a member of the modeling domain in order for the trust status control call to succeed. With this implementation, substituting an alternate process would now require that an adversary break the security context between the TMA and process in the modeling domain. > > > > + state HEXID: > > > > + The state keyword is used to indicate that the > > > > + security state point identified by the ASCII > > > > + base 16 encoded value should be loaded into > > > > + the current security model as a valid security > > > > + event state. > > > > + > > > > + pseudonym HEXID > > > > + The pseudonym keyword is used to indicate that > > > > + the pathname, identified by the 256 bit ASCII > > > > + base 16 encoded value HEXID, should be > > > > + designated to return a constant digest value > > > > + for the contents of the file. > > > > + > > > > + The HEXID value is computed with the following > > > > + function: > > > > + > > > > + HEXID = SHA256(PATHNAME_LENGTH || PATHNAME) > > > > > This seems like an unusual design choice, and perhaps one born from > > > necessity ... ? It's nice that it is opt-in, but I would be curious > > > to hear what problems this solved. > > > > It is an approximation method that allows things like log files and > > .bash_history files to be effectively modeled. > > Okay, that's what I suspected, I just wanted to make sure there wasn't > something else I was missing. > > > > > + base HEXID > > > > + The base keyword is used to indicate that the > > > > + 256 bit ASCII base 16 encoded value HEXID > > > > + should be registered as the value used to > > > > + generate model specific security event points. > > > > + > > > > + A model specific base value is designed to be > > > > + used as a 'freshness' nonce, similar to an > > > > + attestation nonce, to prove that a model state > > > > + value or measurement is current and not being > > > > + replayed. > > > > diff --git a/Documentation/admin-guide/LSM/tsem.rst b/Documentation/admin-guide/LSM/tsem.rst > > > > new file mode 100644 > > > > index 000000000000..f03e5269cd25 > > > > --- /dev/null > > > > +++ b/Documentation/admin-guide/LSM/tsem.rst > > > > @@ -0,0 +1,1240 @@ > > > > +==== > > > > +TSEM > > > > +==== > > > > > > ... > > > > > > > +Process and Platform Trust Status > > > > +================================= > > > > + > > > > +A fundamental concept in TSEM is the notion of providing a precise > > > > +definition for what it means for a platform or workload to be trusted. > > > > +A trusted platform or workload is one where there has not been an > > > > +attempt by a process to execute a security relevant event that does > > > > +not map into a known security state point. > > > > + > > > > +The process trust status is a characteristic of the process that is > > > > +passed to any subordinate processes that are descendants of that > > > > +process. Once a process is tagged as untrusted, that characteristic > > > > +cannot be removed from the process. In a 'fruit from the poisoned > > > > +vine' paradigm, all subordinate processes created by an untrusted > > > > +process are untrusted as well. > > > > + > > > > +On entry into each TSEM security event handler, the trust status of a > > > > +process is checked before an attempt to model the event is made. An > > > > +attempt to execute a security event by an untrusted process will cause > > > > +the event, and its characteristics, to be logged. The return status > > > > +of the hook will be determined by the enforcement state of the model. > > > > +A permission denial is only returned if the TMA is running in > > > > +enforcing mode. > > > > + > > > > +If the platform running the TSEM LSM has a TPM, the hardware aggregate > > > > +value is computed at the time that TSEM is initialized. This hardware > > > > +aggregate value is the linear extension sum over Platform > > > > +Configuration Registers (PCR's) 0 through 7. This is the same > > > > +aggregate value that is computed by the Integrity Measurement > > > > +Architecture (IMA) and is the industry standard method of providing an > > > > +evaluation measurement of the hardware platform state. > > > > + > > > > +Internally model domains have the hardware aggregate measurement > > > > +included as the first state point in the security model. Externally > > > > +modeled domains export the hardware aggregate value to the TMA for > > > > +inclusion as the first state point of the model maintained by the TMA. > > > > + > > > > +The root modeling domain extends each security state point into PCR > > > > +11. This allows hardware based TSEM measurements to coexist with IMA > > > > +measurement values. This hardware measurement value can be used to > > > > +attest to the security execution trajectory that the root model > > > > +maintains. > > > > > It seems like making the target PCR configurable would be a good > > > idea, at the very least make it a Kconfig option. > > > > That was something that we have thought about, it probably needs a > > Kconfig option. > > > > Contrary to all appearances, as a team we are really minimalists at > > heart and tend to not make things more complex or configurable than > > needed.... :-) > > > > > Also, can you elaborate on how the security state points are > > > extended into the PCR? I imagine for it to be useful at an > > > arbitrary point in time this would require the PCR to be extended as > > > the security points were generated, which would imply that the PCR > > > value would be dependent on execution order, and in most cases, > > > scheduling order as well. How useful do you expect this to be for > > > most users? > > > > Your assessment is correct, the state points are extended into the PCR > > whenever a unique security state point is generated. > > > > In a 'free-running' model, the value in the register will be fungible > > due to scheduling dependencies. > In other words, garbage ;) We don't disagree on the utility of a scheduling fungible measurement value. However, this is an remarkably interesting conclusion/statement, by the Linux security sub-system maintainer no less, given that it describes the current state of the art with respect to hardware security co-processors and trusted system technology.. :-) > > If the model is pre-defined, the security state points will be > > extended into the register as they are loaded through the > > /sys/fs/tsem/map pseudo-file interface. In this case, the value will > > be fixed and any departure from the value would signal that the > > modeling domain has departed from its specification. > > > > With respect to the utility of the value, in a 'free-running' model it > > is about as useful as the value that IMA maintains in PCR 10, which in > > our opinion is not very useful and is why we implemented the notion of > > the 'state' value of a model. > For a variety of reasons, and mostly to help keep things civil, > let's refrain from comparing one LSM to another. Each LSM makes its > own choices, and needs to stand on its own; just because LSM did X > doesn't mean TSEM can do X if it is silly in the context of TSEM. Our intent was not to be incivil, but rather to call out one of the motivations in the implementation of TSEM, and in a larger context, the notion of a TMA based security architecture. A now prehistoric version of TSEM was implemented as a patch on top of IMA. We actually built systems for clients on top of that architecture. Our concept of a 'state' value was driven by the difficulties we experienced in implementing, and maintaining, these systems in a field environment. We offer the concept of a 'state' value in order to simplify the attestation model, which classically, has required that a verifying party review an event log for its validity, after verifying that the measurement value confirms the integrity of the log. > > The primary utility of the value is that it is a hardware maintained > > reference value that can be used to confirm the set of measurements > > committed to the register. > Given that the PCR value is only deterministic in the case of a > predefined policy/model, it seems like it would be worth stating that > a bit more clearly in the docs. We thought it was covered thoroughly in the 'Security model functional definitions' section of the tsem.rst file, but we are reviewing all of that, including the context of the ABI documentation. > > So our 'state' value gives us a constant 'good' value for the security > > model. The PCR 11 value provides a hardware root of trust for the set > > of points that lead to the state value. > Just to make sure I understand you, in the predefined case PCR 11 is > extended with the SRTM PCRs as well as a measurement of the TSEM > policy at load time, yes? To be clear, PCR 11 is only extended for events generated in the root modeling domain, a TMA acts as a virtual TPM so it maintains its own measurement values. To the specific point, you are correct, the aggregate value is injected as the first measurement into a modeling domain. > > > > +Internal vs external modeling > > > > +----------------------------- > > > > + > > > > +When a TSEM modeling domain is created, a designation is made as to > > > > +whether the domain is to be internally or externally modeled. > > > > + > > > > +In an internally modeled domain, the security event handlers pass the > > > > +event type and its characteristics to the designated internal trusted > > > > +modeling agent. The agent provides the permission value for the > > > > +security event handler to return as the result of the event and sets > > > > +the trust status of the process executing the event. > > > > + > > > > +In an externally modeled domain, the event type and parameters are > > > > +exported to userspace for processing by a trust orchestrator with an > > > > +associated TMA. The trust orchestrator communicates the result of the > > > > +modeling back to the kernel to support the setting of the process > > > > +trust status. > > > > + > > > > +This model poses a limitation to the ability of TSEM to model some > > > > +security events. This is secondary to the fact that some event > > > > +handlers (LSM hooks) are called from a non-sleeping context, as a > > > > +result the process cannot be scheduled. This is particularly the case > > > > +with the task based hooks, since they are typically called with the > > > > +tasklist lock held. > > > > + > > > > +This limitation is also inherent to the root model that extends the > > > > +security state points into TPM PCR 11, secondary to the fact that the > > > > +process invoking the security event hook will be scheduled away while > > > > +the TPM transaction completes. > > > > + > > > > +Addressing this problem directly requires a consideration of the > > > > +context from which the security event handlers are being called. > > > > +Subsequent implementations of TSEM will include a mechanism for > > > > +asynchronous deferral of model processing, until when and if, a review > > > > +of the call context would be considered worthwhile by the LSM > > > > +community. > > > > > This is a pretty big limitation, and in conjunction with the some of > > > the other issues brought up earlier (the PID issue seems the most > > > concerning), I'm having a difficult time believeing that an external > > > modeler could operate safely given the design presented here. > > > > With respect to the PID issue, we would welcome any comments on the > > analysis that we provided above as to its design safety. > > >From what I can tell from the documentation and our discussion thus > far is that TSEM relies on a security_task_kill() hook implementation > to ensure that a process is not killed, and the PID released, without > explicit TSEM approval. Unfortunately, I believe that relying solely > on security_task_kill() will not fully cover all of the cases where a > process can be killed, mostly because security_task_kill() does not > control process destruction, it controls the ability of one process to > signal another. > You might be able to do something with security_task_free(), but I > haven't given that much thought. Our analysis suggested that an authentication strategy was the strongest and most complete implementation moving forward. > > If the PID issue remains a concern, we have an extension to the export > > descriptions that would include a random nonce that would be emitted > > with the PID. The nonce would be placed in the LSM task control > > 'blob' for the sleeping task and used to confirm that the task release > > directive was acting on the correct process. > That should help, but ultimately a nonce is still a bounded resource > and subject to recycling just like the PID. I'm open to hearing > other ways in which you believe you can resolve this issue, but I > remain skeptical. FWIW, I believe that current thinking is that a nonce based on a 64-bit value is immune from recycling. The classic metric for a 64-bit counter is that a consumption rate of 1000 values/second yields a counter cycle time of 584,942,417 years. Nanosecond rates still buys you 584 years. I believe that Jason built the Wireguard protocol on this predicate. We believe the second series will fully address this issue, without using nonces, for whatever that is worth. We can reserve further discussion once that code is available and submitted for review. > > > Unfortunately, there will always be LSM hooks which need to operate > > > in a non-blocking context, meaning this challenge is here to stay. > > > Help me understand how you could safely do asynchronous policy > > > enforcement with an external modeler, I'm not sure it's possible. > > > > Electing to implement asynchronous enforcement would require further > > thought. We were operating in the context of full disclosure in our > > documentation and wanted to be up front about limitations and options. > > > > To be clear, at this time, we are not advocating for or bringing > > forward an asynchronous update architecture. > > > > So, at this time, there is a well understood modeling limitation with > > respect to the LSM hook implementations. That limitation is not > > limited to external TMA's, since the event state points cannot be > > extended into a TPM in a non-blocking context. > I think these limitations need to be made explicit in the > documentation. If the TSEM security model can not be faithfully > implemented, the documented security model may need to change. We will further explain the trade-offs between the different modeling environments in the documentation. > > > Frankly, I also wonder how a system would perform with an external > > > modeler, indepdent of the issues with non-blocking hooks. How does > > > the system perform with every blockable LSM hook invocation > > > potentially blocking on a response from userspace? Or with the COE > > > being somewhat coarse, does the trajectory/policy populate itself > > > quickly? > > > > One obviously experiences a latency hit in going to userspace, by > > definition, implementing security always has an associated resource > > cost. So, once again, this comes down to a cost/benefit analysis. > > > > As a Gedanken exercise, consider the value proposition of a Linux > > based RTU, or other device, controlling infrastructure that can only > > execute security relevant events that are guaranteed to be known good > > by an external co-processor that is only accessible as a security > > oracle. > > > > Given that frame of reference. > > > > Time for a userspace or SGX based TMA transaction is running around > > 890 micro-seconds. > > > > Going to a TMA based in a Xen stubdomain implementation runs a bit > > longer, probably around 940 micro-seconds or so. > > > > The micro-controller implementations are decidedly slower, with the > > NRF52840-DONGLE clocking in at around 40 micro-seconds, but that is > > strictly a CPU horsepower issue. > > > > All of this with the caveat that we have been focusing almost > > exclusively on correctness and not optimizing performance. > > > > We've thought a bit, mainly on long walks with our Golden Retriever > > Izzy, about the issue of building a kernel based policy cache with > > externally modeled domains. Given that the kernel does not, a-priori, > > know what modeling algorithm a TMA might be using, we would need to > > come up with a method of deterministically mapping a security event > > description to a known good state point value. > > > > The other issue with all this is that with containerized workloads, > > particularly micro-services, the rate of security event generation can > > be surprisingly low. Obviously this is also the case with embedded > > implementations. > > > > Once again, what are you willing to pay to be safe? > For better or worse, when code is proposed for the upstream Linux > Kernel it is subject to scrutiny from all manner of developers and > users, with most being focused on their own pet projects/subsystems, > not whatever new security promises you are providing. > > There have been patch(sets) and discussions relating to performance > gains/losses on the other of tens of nanoseconds per operation. > > I think most of us in the security community are sympathetic to the > question of "what are you willing to pay to be safe", but please > understand that while we are understanding, there are others who will > disagree not only with the performance cost tradeoff, but the very > idea of safety you are promising. My only suggestion is to be > prepared, and be honest with the performance assessments of TSEM. We seem to be in agreement that there will always be a natural tension between security and performance. With TSEM our goal is to offer choices. If an environment is sensitive to performance defects on the order of tens of nanoseconds, it would seem unlikely that the architects or administrators of such systems would be implementing integrity controls of any kind. In that context, we are no different than IMA or IPE, it would seem highly unlikely that such environments are going to tolerate a security solution involving a cryptographic checksum of any type. fTPM's and embedding TPM style functionality on the core, ie. the Microsoft Pluton model, may change all of this, but currently hitting a discrete TPM isn't a fast operation either. So, with respect to choices. We offer the tsem_mode= kernel command-line argument in order to support only namespace based modeling. In that configuration, the performance penalty is paid only by workloads where a decision is made to run them in a modeled security environment. From that point, you have a choice on whether a security namespace should be internally or externally modeled. Optimum performance, of course, would be with an internally modeled domain. There is also the option of completely disabling TSEM by using the 'lsm=' command-line option So hopefully all of this indicates honesty with respect to performance issues. In any event, we will make it clear in the documentation that electing to use external modeling will have a performance hit and the mechanisms available for addressing that issue. With respect to external modeling, significant advantage is that it opens the door to being able to implement alternate security models without writing kernel code, which is not inconsequential, given the challenges to working in kernel context let alone getting code upstreamed and accepted by distributions. In some cases, such as SGX, the only way to integrate those types of protections into a TMA architecture is to go to userspace. We currently have micro-controller based TMA implementations that have embedded CAT-1M cellular modems that allow modeling, auditing and alerting to be done entirely outside of the kernel. It is probably no surprise that it is profoundly easier to build these types of architectures outside of the kernel. > > > > +Event handlers that cannot be directly modeled, still consider, on > > > > +entry, whether or not they are being called by an trusted or untrusted > > > > +process. As a result, an untrusted process will cause a non-modeled > > > > +event to return a permissions violation in enforcing mode, even if the > > > > +security event cannot be directly modeled. > > > > + > > > > +Security event modeling typically traps violations of trust by a COE > > > > +with unmodeled characteristics that is attempting to access/execute a > > > > +file or map memory as executable; or by a COE with known > > > > +characteristics attempting to access or execute a CELL not prescribed > > > > +by a model. As a result, the impact of the ability to not directly > > > > +model these events is lessened. > > > > > > ... > > > > > > > +Event modeling > > > > +-------------- > > > > + > > > > +TSEM security event modeling is based on the following functional > > > > +definition for a security state point: > > > > + > > > > +Sp = SHA256(SHA256(EVENT_ID) || TASK_ID || SHA256(COE) || SHA256(CELL)) > > > > > It appears that all of the hasing in TSEM is SHA256 based, you might > > > want to consider making that a Kconfig option at the very least. > > > > That has been something that we have talked about as well. > > > > As I indicated previously, we really are minimalists, particularly > > after watching IMA fight with issues surrounding algorithmic agility. > > > > It would be easy enough to make this configurable but does anyone see > > SHA256 as not being useful in in this role anywhere in the next 10 > > years? > There are any number of reasons why one might need to select a > different hash algorithm: legal constraints, security > certifications, corporate policy. I would strongly suggest making > this configurable. Certainly sound and well reasoned advice, but the question then becomes what hashes and what hash lengths, do you have any specific recommendations? IMA currently has the options of SHA1, SHA256, SHA512, WHIRLPOOL512 and SM3; is this sufficient coverage, given that SHA1 in a new implementation like TSEM probably doesn't make any sense? Our current inclination, for the initial release, in an embrace of minimalisim, would be to make this a selectable option when a modeling domain is setup, with the only selectable option being SHA256. This would place the onus on userspace to make the decision and doesn't lock the kernel to an ABI. We would obviously pair this with a kernel command-line option for the root modeling domain. In the meantime we will start work on the infrastructure needed to support an adequate amount of 'cryptographic agility', whatever group consensus would suggest that to be.. > paul-moore.com Let us know if we can provide any additional clarifications. Otherwise, the most efficient use of your review time would be to give us a quick overview on any style issues you see. The second patch series already represents a sufficient delta that time spent reviewing the current code for correctnes wouldn't be an optimum use of your time. Best wishes for a productive week. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity
On Mon, Mar 13, 2023 at 6:52 PM Dr. Greg <greg@enjellic.com> wrote: > On Thu, Mar 02, 2023 at 11:15:56PM -0500, Paul Moore wrote: > > Hi Paul, thanks for sending along further comments. > > You note below that you haven't had time to look at the code since you > wanted to confirm the TSEM security model before moving forward. > > From a development perspective we are now three weeks into what will > become version 2 of the patch series. So at this point I wouldn't > advocate spending a lot of time on the current patchset. > > That being said, if you some have time, we would appreciate a quick > look at the code on your part, with respect to style changes and the > like we can enforce in the second series, ie. ordering of local > variable declarations by length and the like. To be perfectly honest I'm still very concerned about some of the issues that I've seen in the docs, until that is sorted out I'm not sure there is much point in looking at the code. > > On Tue, Feb 14, 2023 at 6:58???AM Dr. Greg <greg@enjellic.com> wrote: > > > On Sun, Feb 12, 2023 at 11:33:26PM -0500, Paul Moore wrote: > > > > On Sat, Feb 4, 2023 at 12:33 AM Dr. Greg <greg@enjellic.com> wrote: > > > > > > > > > > An entry was added to the ABI testing documentation to document > > > > > the files in the TSEM management filesystem. > > > > > > > > > > The file documenting the kernel command-line parameters was > > > > > updated to document the tsem_mode command-line parameter. > > > > > > > > > > The primary TSEM documentation file was added to the LSM > > > > > administration guide and the file was linked to the index of LSM > > > > > documentation. > > > > > > > > > > Signed-off-by: Greg Wettstein <greg@enjellic.com> > > > > > --- > > > > > Documentation/ABI/testing/tsemfs | 576 ++++++++ > > > > > Documentation/admin-guide/LSM/index.rst | 1 + > > > > > Documentation/admin-guide/LSM/tsem.rst | 1240 +++++++++++++++++ > > > > > .../admin-guide/kernel-parameters.txt | 5 + > > > > > 4 files changed, 1822 insertions(+) > > > > > create mode 100644 Documentation/ABI/testing/tsemfs > > > > > create mode 100644 Documentation/admin-guide/LSM/tsem.rst > > > > > > > One of the more important requirements for any new LSM is that it > > > > documents a clear, understandable, and reasonable security model along > > > > with an implementation that faithfully implements that model. Before > > > > I looked at your code I wanted to try and understand the TSEM security > > > > model and a few things jumped out at me rather quickly, I imagine > > > > there would be others as I start to look a bit closer but I wanted to > > > > send these questions/comments along now to get your take on them ... > > > > > > Hi Paul, thanks for taking time to review the documentation and raise > > > questions, responses below. > > > > > > > > diff --git a/Documentation/ABI/testing/tsemfs b/Documentation/ABI/testing/tsemfs > > > > > new file mode 100644 > > > > > index 000000000000..3d326934624c > > > > > --- /dev/null > > > > > +++ b/Documentation/ABI/testing/tsemfs > > > > ... > > > > > > > +What: /sys/fs/tsem/measurement > > > > > +Date: November 2022 > > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > > +Description: > > > > > + The measurement file contains the ASCII base 16 > > > > > + hexadecimal representation of the 256 bit measurement > > > > > + value of the security model that the process is > > > > > + operating in. > > > > > + > > > > > + The measurement value is the classic linear extension > > > > > + measurement of the model. An updated measurement > > > > > + value is created by extending the current measurement > > > > > + value with the state coefficient computed for a > > > > > + security event. > > > > > + > > > > > + This measurement value represents a time dependent > > > > > + measurement of a model and is susceptible to > > > > > + deviations caused by scheduling differences between > > > > > + subsequent invocations of a workload. > > > > > > > Given the very volatile nature of this value, what is it used for in > > > > userspace? My apologies if I missed it in the docs. > > > > > > It serves the same role as PCR register 10 in IMA, or any other > > > register in a TPM based architecture using a classic linear extension > > > mechanism strategy, it can be used to validate a list of time or > > > sequence ordered measurement values. > > > > > > Our personal prejudice is that these types of measurements are of > > > limited value, which is why we introduce in TSEM, the notion of the > > > 'state' value for a model, discussed below. > > > > > > I would have to go looking on lore for a reference to the exact thread > > > but Roberto Sassu had offered up a patch set for IMA that addressed > > > the deficiency of these types of measurements. > > > If we all agree that this measurement isn't very useful, and you > > have implemented an alternative which is intended to address these > > usability shortcomings, why bother including this measurement in > > TSEM? > > To provide comparable functionality to TPM based security > architectures, that are currently, considered state of the art for the > security industry. > > As our documentation calls out, TSEM's concept of Trusted Modeling > Agent's (TMA's), are being proposed to both explore and implement next > generation hardware assisted security technologies. > > Currently, the only measurements that TPM based systems support are > classic linear extension summing, which I believe we all consider to > be problematic. > > That being said, the 'measurement' value can be used to validate the > order of the security event execution trajectory. In that role it > provides the same value that PCR register 10 plays for IMA. > > We believe there is a legitimate discussion that can occur, as to > whether or not this classic attestation architecture is relevant, but > it seemed appropriate to support it. It is relatively easy to add user visible features to the kernel, but it's almost impossible to remove them. If you see little value in feature X, to the point that you've developed an alternate mechanism to avoid the shortcomings which limit the usefulness of X, why include it? If you later realize that it is important you can always add it. Add new functionality to the kernel because it meets a user need, not simply because "everybody else is doing it". If you've got a defined use case for this, keep it; however, if you can't define a reasonable use case I would suggest dropping it and making your life easier. > > It's relatively easy to add features to the Linux Kernel as time > > goes on, it is *very* difficult to remove them. For this initial > > submission I would encourage you to implement the bare minimum > > functionality you need to do something useful and meet your goals. > > We can certainly pull the export of the measurement value. In that > case, would you recommend that we also pull the code that extends the > security coefficients from the root modeling domain, if a TPM is > available, into PCR register 11? Once again, if you've got a use case, keep it; if not, drop it. Don't add to the kernel API without a use case. > > > > > +What: /sys/fs/tsem/trajectory > > > > > +Date: November 2022 > > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > > +Description: > > > > > + The trajectory file contains a description of the > > > > > + security events that have occurred in a security > > > > > + domain/model. > > > > > + > > > > > + Each entry in this file represents a single security > > > > > + event and consists of brace {} delimited fields that > > > > > + describe the characteristics of a security event. > > > > > + Each field has key=value pairs that define > > > > > + characteristics of the field. > > > > > + > > > > > + Each line in a trajectory, or forensics, file will > > > > > + always have the event{} and COE{} fields. The event > > > > > + field describes the characteristics of a security > > > > > + event while the COE field describes the Context Of > > > > > + Execution that is executing the security event. > > > > > > > I think it would be good to provide a concrete definition of > > > > CELL_DEFINITION field as other areas of the documentation make > > > > reference to it within the tsem/trajectory file documentation. We can > > > > somewhat infer it's format, fields, etc. but it's much better to be > > > > explicit about these things. > > > > > > Valid point, we will incorporate a broad definition of what the 'CELL' > > > represents. > > > > > > Conceptually, it is equivalent to the 'object' in mandatory access > > > controls. In an events based architecture like TSEM, it is > > > essentially the 'bucket' of values that describe the parameters of a > > > security event that a COE/process is requesting permission for. > > > Yes, I understood conceptually what it represents and what data > > might be present given a specific operation/rule, but it wasn't > > clear to me how that data would be represented in the > > CELL_DEFINITION. > > As a bit of further clarification, regarding the security model that > TSEM is based on. > > A TMA extracts the event description parameters, now encoded in > JSON.. :-), into a structure and then computes a digest value, > referred to as the 'CELL identity value', over those elements, in > whatever order the TMA elects to do so in. > > Further, a TMA implementation may elect to only include certain > characteristics in the computation of the CELL identity, depending on > the model being implemented. > > > > > > + The event{} field consists of the following > > > > > + characteristic definitions: > > > > > > > I'm unclear as to the purpose of the event{} field as it is neither > > > > part of the COE or the CELL, is it here simply to make the event > > > > easier to read? Or am I misunderstanding things and the event{} > > > > field is part of the COE? > > > > > > It actually serves two roles, one of which, as you note, is to make > > > the event description easier to read and understand. > > > > > > It probably comes as no surprise, but the trust orchestration system > > > that this is all designed to support, has a security console that can > > > be used to review the status of all the trust orchestrators that are > > > supervising security workloads. Either in the cloud, or perhaps, a > > > large body of edge devices protecting critical infrastructure, if that > > > doesn't give away too much.... :-) > > > > > > Having the process name and executable easily visualized is fairly > > > useful. > > > > > > The second role is to allow the event description records to be > > > self-describing. The value for the type= key is used by the Trusted > > > Modeling Agent (TMA) to determine what to look for in the remainder of > > > the event description record in order to compute the CELL value. > > > > > > It also contains the TASK_ID value that ties the security state points > > > to the integrity of the executable. Since that value is a synthetic > > > value it was deemed most appropriate to be placed in the event{} > > > field. > > > I think it would be good to provide a more succinct version of the > > above in the documentation. > > We will clarify that. > > > > > > + process=COMM > > > > > + Where COMM is the ASCII representation > > > > > + of the name of the process executing > > > > > + the event. > > > > > + > > > > > + filename=PATH > > > > > + If the CELL definition for an event > > > > > + references a file the filename > > > > > + characteristic contains a definition > > > > > + of the path to the file. > > > > > + > > > > > + In the case where an event does not > > > > > + have a file the PATH value is set to a > > > > > + value of none. > > > > > > > What happens in cases where multiple file paths are present in an > > > > event? Also, given this is visible to userspace, and multiple > > > > things can affect the path to a file (e.g. namespaces), how is the > > > > file path determined? > > > > > > Unless we have missed something, which is no doubt possible, all of > > > the security event hooks that we have implemented, which number about > > > 87 now, that act on a 'file', receive only a single 'struct file *' > > > pointer as a parameter to the event. > > > > > > So we haven't encountered a situation where there would be multiple > > > files for a single event description. > > > I haven't seriously looked at the TSEM sources yet, I'm trying to > > make sure that I first understand the security model while also > > ensuring that it is well documented and reasonable. While I can't > > speak to what LSM hooks TSEM implements, it seems like there are at > > least a few operations, rename and link come immediately to mind, > > which would have multiple filenames as part of the operation. How > > are those operations handled in TSEM, or are they outside the scope > > of TSEM? > > We are currently handling them as generically modeled events so the > current model treats them as whether or not they occurred. > > When they get promoted to explicitly modeled events, the current > presumption would be to include the involved filenames in the > description of the event. Hmmm. With the understanding that I didn't go re-read the docs just now, my gut feeling is that omitting/downgrading events like rename/link/etc. from the modeling is a pretty significant shortcoming given the importance of filenames as an identifier in the TSEM events. The fact that you chose to say "When they get promoted ..." as opposed to "If they get promited ..." appears to add some credibility to that thought. However, I will be honest and say that I'm not sure I recall the difference between "generically modeled" and "explicitly modeled" events in the context of TSEM. Perhaps that would make this clear, maybe it wouldn't. Regardless, can you help me understand why this isn't a concern for this initial effort and why you've decided to add this later? > > > > > + euid=NN > > > > > + The ASCII base 10 representation of > > > > > + the numeric value of the effective > > > > > + discretionary user id of the process > > > > > + that is executing the security event. > > > > > + > > > > > + euid=NN > > > > > + The ASCII base 10 representation of > > > > > + the numeric value of the effective > > > > > + discretionary user id of the process > > > > > + that is executing the security event. > > > > > + > > > > > + suid=NN > > > > > + The ASCII base 10 representation of > > > > > + the numeric value of the saved user id > > > > > + of the process that is executing the > > > > > + security event. > > > > > + > > > > > + gid=NN > > > > > + The ASCII base 10 representation of > > > > > + the numeric value of the discretionary > > > > > + group id of the process that is > > > > > + executing the security event. > > > > > + > > > > > + egid=NN > > > > > + The ASCII base 10 representation of > > > > > + the numeric value of the discretionary > > > > > + effective group id of the process that > > > > > + is executing the security event. > > > > > + > > > > > + egid=NN > > > > > + The ASCII base 10 representation of > > > > > + the numeric value of the discretionary > > > > > + effective group id of the process that > > > > > + is executing the security event. > > > > > + > > > > > + sgid=NN > > > > > + The base 10 ASCII representation of > > > > > + the numeric value of the saved > > > > > + discretionary group id of the process > > > > > + that is executing the security event. > > > > > + > > > > > + fsuid=NN > > > > > + The base 10 ASCII representation of > > > > > + the numeric value of the discretionary > > > > > + filesystem user id of the process that > > > > > + is executing the security event. > > > > > + > > > > > + fsgid=NN > > > > > + The ASCII base 10 representation of > > > > > + the numeric value of the discretionary > > > > > + filesystem group id of the process > > > > > + that is executing the security event. > > > > > + > > > > > + cap=0xNNN > > > > > + The ASCII base 16 representation of > > > > > + the numeric value of effective > > > > > + capabilities of the process that is > > > > > + executing the security event. > > > > > + > > > > > + If the CELL value for a security event includes the > > > > > + definition of a file a file{} event field will be > > > > > + included. The following characteristics will be > > > > > + encoded in this field: > > > > > + > > > > > + flags=NN > > > > > + The ASCII base 10 representation of > > > > > + the flags value of the 'struct file' > > > > > + structure that is the source of the > > > > > + file description. > > > > > + > > > > > + uid=NN > > > > > + The ASCII base 10 representation of > > > > > + the discretionary user id of the file. > > > > > + > > > > > + gid=NN > > > > > + The base 10 ASCII representation of > > > > > + the discretionary group id of the > > > > > + file. > > > > > > > Similar to the task UID/GID mapping questions above, there are > > > > mechanisms which map the file user/group IDs, which will be used in > > > > the CELL definition and how will that be resolved between the kernel > > > > and an external modeler? > > > > > > The answer is the same as with the COE, see the following function: > > > > > > security/tsem/event.c:get_file_cell() > > > > > > Once again, the TMA only operates on the event description presented > > > to it and is not influenced by its own namespace. > > > For this particular point, my concern isn't what policy the TMA > > implements, or what it uses as input, it's about understanding how > > this event information is collected. For fields which can be > > namespaced (I'm referring to "normal" Linux Kernel namespaces and > > not any TSEM namespaces), the TSEM documentation should make it > > clear which namespace is used as a basis for the value. > > FWIW, based on feedback we have received, there may be a modeling > domain/namspace setup option forthcoming that allows a trust > orchestrator to request that the uid/gid et.al characteristics be > exported in the context of the current user namespace. Please make sure you are explicit in which "current user namespace": the namespace which generated the event, or the namespace in which the modeling agent is running. You should also provide some guidance on how to handle issues that might arise when the two namespaces (generating namespace, modeler namespace) are different. If you don't plan to allow the modeling agent to run in a separate namespace from the generating event stream please explain how that requirement will be enforced by the kernel. > > > > > +What: /sys/fs/tsem/ExternalTMA > > > > > +Date: November 2022 > > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > > +Description: > > > > > + The ExternalTMA directory is a container directory > > > > > + that hold files that will be used to export the > > > > > + security events, and their associated parameters, for > > > > > + externally modeled security domains/namespaces. > > > > > + > > > > > + The files created in this directory will be named by > > > > > + the base 10 ASCII representation of the id value > > > > > + assigned to the modeling domain/namespace. See the > > > > > + documentation for the /sys/fs/tsem/id file in this > > > > > + documentation for more details on this value. > > > > > + > > > > > + This file will is a read-only file that can be polled > > > > > + by a userspace trust orchestration implementation to > > > > > + process security events that are to be modeled by > > > > > + an external Trusted Modeling Agent. > > > > > + > > > > > + The type of the exported event is the first keyword of > > > > > + the line that is output and have the following > > > > > + values and arguments: > > > > > + > > > > > + aggregate HEXID: > > > > > + Where HEXID is the ASCII base 16 > > > > > + representation of the 256 bit hardware > > > > > + platform aggregate value. > > > > > + > > > > > + export pid{NNN} COE{} CELL_DEFINITION > > > > > + Where the NNN in the pid field is the ASCII > > > > > + base 10 value of the id of the process that is > > > > > + executing the security event that will be > > > > > + modeled. > > > > > > > I worry whenever I see a PID used as an identifier shared across the > > > > kernel/userspace boundary as it is inherently racy. Given the > > > > somewhat coarse COE definition where one can expect multiple > > > > processes/PIDs to share the same COE value, and the ability of > > > > untrusted users/processes to manipulate the PID table, what do you > > > > expect to use the pid{NNN} field for in this event? > > > > > > > > Similar to the other namespace/mapping issues discussed previously, > > > > there is also the PID namespace issue to worry about. How is that > > > > handled here? > > > > > > The concern over the PID issue is understandable, I will treat the > > > reasoning behind its use below. > > > > > > The PID value is the 'native' value managed by the kernel, not a > > > mapped value. > > > Regardless of if the PID is rooted in the initial namespace or a > > different PID namespace, the issue of PIDs being inherently racy is > > a real problem. Can you help me understand how TSEM avoids the > > common pitfalls associated with using PIDs to identify processes on > > the system? > > The second version of the TSEM series, now includes support for a > requirement that a process being externally modeled, authenticate > itself to the TMA in order for the trust control call to act on > the process. Please bear with me, I want to make sure I'm clear on this point. In order for a process to be modeled by an external modeling-agent/TMA it would need to first authenticate with the TMA (using a TBD mechanism); is that correct? I guess we will need to see how the authentication works, but is there a mechanism in place to ensure that a malicious process could not pass an authentication token to another (PID recycled) process? Do you plan to support unauthenticated external modeling? If so, how do you plan to address PID recycling? > > > > > +What: /sys/fs/tsem/control > > > > > +Date: November 2022 > > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > > +Description: > > > > > + The control file is the only writable file in the > > > > > + filesystem and is used by the trust orchestrators to > > > > > + configure and control the behavior of the TSEM > > > > > + implementation. > > > > > + > > > > > + The following keyword and arguments are recognized: > > > > > + > > > > > + internal: > > > > > + The internal keyword causes an internally > > > > > + modeled domain to be created for the calling > > > > > + process. > > > > > + > > > > > + external: > > > > > + The external keyword causes an externally > > > > > + modeled domain to be created for the calling > > > > > + process. > > > > > + > > > > > + enforce: > > > > > + The enforce keyword causes the modeling > > > > > + domain/namespace of the process to enter > > > > > + enforcing mode. In this mode a value of > > > > > + -EPERM will be returned for a security event > > > > > + that does not map into the current set of > > > > > + allowed state points for the security model > > > > > + being implemented for the domain/namespace. > > > > > + > > > > > + seal: > > > > > + The seal keyword causes the security model > > > > > + being implemented for the model to be placed > > > > > + in sealed state. In this state the current > > > > > + set of security event points is considered to > > > > > + be the only set of valid points for the > > > > > + domain/model. Any subsequent events that map > > > > > + to a point not in the current model will be > > > > > + considered a violation of the model. > > > > > + > > > > > + trusted PID: > > > > > + The trusted keyword is used by a trust > > > > > + orchestrator to indicate that the process > > > > > + identified by the PID argument should be > > > > > + allowed to run in trusted status. > > > > > + > > > > > + untrusted PID: > > > > > + The untrusted keyword is used by a trust > > > > > + orchestrator to indicate that the process > > > > > + identified by the PID argument should be > > > > > + allowed to run but designated as an untrusted > > > > > + process. > > > > > > > The 'trusted PID:' and 'untrusted PID:' commands are concerning for > > > > the reasons described above about PIDs being racy and generally an > > > > unreliable way of identifying processes across the kernel/userspace > > > > boundary. I suspect it would not be too difficult for a malicious > > > > user to trick an external modeler into marking the wrong process as > > > > trusted/untrusted. > > > > > > An external TMA needs the PID value to determine which process to wake > > > up and set the trust status value on in the task control structure, > > > after the event is modeled. As was noted above, the PID value is the > > > unmapped value maintained by the OS. > > > > > > Lets see if we can reason through why the PID can be used safely. > > > > > > CAP_TRUST, or whatever ends up getting used, is required by the trust > > > orchestrator to create a security/modeling namespace for the workload > > > being modeled. This results in the creation of the following > > > pseudo-file for surfacing the security event descriptions for the > > > namespace/workload: > > > > > > /sys/fs/tsem/ExternalTMA/N > > > > > > Where N is the id number of the modeling domain. > > > > > > CAP_TRUST, caveats applied, is required to open the pseudo-file. The > > > trust orchestrator only receives and acts on PID values through this > > > conduit from the kernel. > > > > > > When an event description is exported, the trust status of the task is > > > set to 'pending' and the process is placed in interruptible sleep and > > > scheduled away, with the 'wakeup' criteria being the trust status > > > being changed from pending to either trusted or untrusted. > > > > > > The only path to change the trust status value in the LSM task control > > > structure and wake up the process is by the trust orchestrator that > > > created the namespace, by writing the appropriate value to the > > > /sys/fs/tsem/control file. Access to that file is gated by CAP_TRUST > > > or its equivalent. > > > > > > See the following code locations for further details: > > > > > > security/tsem/export.c:tsem_export_event() > > > > > > security/tsem/fs.c:control_COE() > > > > > > As long as the process 'exists', albeit sleeping, the PID slot is > > > occupied and an adversary, regardless of namespace, cannot substitute > > > a task with the same PID value. > > > > > > This leaves an adversary with the need to terminate the task being > > > modeled in order to capture its PID slot. > > > > > > Precautions are implemented in the following function to protect the > > > process from being terminated by an adversary: > > > > > > security/tsem/tsem.c:tsem_task_kill() > > > What about the OOM killer? > > > > The security_task_kill() LSM hook only offers an access control point > > for one process sending another process a signal, it doesn't gate a > > process being killed for other reasons. The OOM killer is the first > > thing that comes to mind, but I'm reasonably certain there are other > > similar scenarios. > > As noted above, as an additional protection, the next version of the > series requires that a process authenticate itself as being a member > of the modeling domain in order for the trust status control call to > succeed. > > With this implementation, substituting an alternate process would now > require that an adversary break the security context between the TMA > and process in the modeling domain. I'll look forward to seeing the new authentication mechanism. Please ensure it is properly documented. > > > > > +Process and Platform Trust Status > > > > > +================================= > > > > > + > > > > > +A fundamental concept in TSEM is the notion of providing a precise > > > > > +definition for what it means for a platform or workload to be trusted. > > > > > +A trusted platform or workload is one where there has not been an > > > > > +attempt by a process to execute a security relevant event that does > > > > > +not map into a known security state point. > > > > > + > > > > > +The process trust status is a characteristic of the process that is > > > > > +passed to any subordinate processes that are descendants of that > > > > > +process. Once a process is tagged as untrusted, that characteristic > > > > > +cannot be removed from the process. In a 'fruit from the poisoned > > > > > +vine' paradigm, all subordinate processes created by an untrusted > > > > > +process are untrusted as well. > > > > > + > > > > > +On entry into each TSEM security event handler, the trust status of a > > > > > +process is checked before an attempt to model the event is made. An > > > > > +attempt to execute a security event by an untrusted process will cause > > > > > +the event, and its characteristics, to be logged. The return status > > > > > +of the hook will be determined by the enforcement state of the model. > > > > > +A permission denial is only returned if the TMA is running in > > > > > +enforcing mode. > > > > > + > > > > > +If the platform running the TSEM LSM has a TPM, the hardware aggregate > > > > > +value is computed at the time that TSEM is initialized. This hardware > > > > > +aggregate value is the linear extension sum over Platform > > > > > +Configuration Registers (PCR's) 0 through 7. This is the same > > > > > +aggregate value that is computed by the Integrity Measurement > > > > > +Architecture (IMA) and is the industry standard method of providing an > > > > > +evaluation measurement of the hardware platform state. > > > > > + > > > > > +Internally model domains have the hardware aggregate measurement > > > > > +included as the first state point in the security model. Externally > > > > > +modeled domains export the hardware aggregate value to the TMA for > > > > > +inclusion as the first state point of the model maintained by the TMA. > > > > > + > > > > > +The root modeling domain extends each security state point into PCR > > > > > +11. This allows hardware based TSEM measurements to coexist with IMA > > > > > +measurement values. This hardware measurement value can be used to > > > > > +attest to the security execution trajectory that the root model > > > > > +maintains. > > > > > > > It seems like making the target PCR configurable would be a good > > > > idea, at the very least make it a Kconfig option. > > > > > > That was something that we have thought about, it probably needs a > > > Kconfig option. > > > > > > Contrary to all appearances, as a team we are really minimalists at > > > heart and tend to not make things more complex or configurable than > > > needed.... :-) > > > > > > > Also, can you elaborate on how the security state points are > > > > extended into the PCR? I imagine for it to be useful at an > > > > arbitrary point in time this would require the PCR to be extended as > > > > the security points were generated, which would imply that the PCR > > > > value would be dependent on execution order, and in most cases, > > > > scheduling order as well. How useful do you expect this to be for > > > > most users? > > > > > > Your assessment is correct, the state points are extended into the PCR > > > whenever a unique security state point is generated. > > > > > > In a 'free-running' model, the value in the register will be fungible > > > due to scheduling dependencies. > > > In other words, garbage ;) > > We don't disagree on the utility of a scheduling fungible measurement > value. However, this is an remarkably interesting > conclusion/statement, by the Linux security sub-system maintainer no > less, given that it describes the current state of the art with > respect to hardware security co-processors and trusted system > technology.. :-) I've yet to meet a kernel maintainer that doesn't hold amusing opinions on at least one issue; one could almost make an argument that it is a prerequisite for the role. However, I feel that using non-deterministic values as a measure of system state/attestation is well understood to be garbage and isn't quite as interesting as you would make it. Based on the rest of the TSEM docs and this discussion, I'm guessing you are referencing IMA's measurements into PCR 10, or something similar, when you talk about the current state of the art, is that correct? In the case of IMA, the important thing to remember is that PCR 10 can be reliably attested using the IMA measurement log; the IMA project even provides tools and documentation demonstrating how to do so. Does TSEM offer a similar measurement log? My apologies if I missed it. > > > If the model is pre-defined, the security state points will be > > > extended into the register as they are loaded through the > > > /sys/fs/tsem/map pseudo-file interface. In this case, the value will > > > be fixed and any departure from the value would signal that the > > > modeling domain has departed from its specification. > > > > > > With respect to the utility of the value, in a 'free-running' model it > > > is about as useful as the value that IMA maintains in PCR 10, which in > > > our opinion is not very useful and is why we implemented the notion of > > > the 'state' value of a model. > > > For a variety of reasons, and mostly to help keep things civil, > > let's refrain from comparing one LSM to another. Each LSM makes its > > own choices, and needs to stand on its own; just because LSM did X > > doesn't mean TSEM can do X if it is silly in the context of TSEM. > > Our intent was not to be incivil, but rather to call out one of the > motivations in the implementation of TSEM, and in a larger context, > the notion of a TMA based security architecture. > > A now prehistoric version of TSEM was implemented as a patch on top of > IMA. We actually built systems for clients on top of that > architecture. Our concept of a 'state' value was driven by the > difficulties we experienced in implementing, and maintaining, these > systems in a field environment. > > We offer the concept of a 'state' value in order to simplify the > attestation model, which classically, has required that a verifying > party review an event log for its validity, after verifying that the > measurement value confirms the integrity of the log. Having a log ordered by the sequence of events can be important. After all, if a security critical configuration knob is toggled multiple times, and the event ordering is not preserved, how does one know the current state of the system? I might be able to see that the knob was turned both on and off, but without knowing which occurred last, how do I know if the system is in a known good state? > > > > > +Internal vs external modeling > > > > > +----------------------------- > > > > > + > > > > > +When a TSEM modeling domain is created, a designation is made as to > > > > > +whether the domain is to be internally or externally modeled. > > > > > + > > > > > +In an internally modeled domain, the security event handlers pass the > > > > > +event type and its characteristics to the designated internal trusted > > > > > +modeling agent. The agent provides the permission value for the > > > > > +security event handler to return as the result of the event and sets > > > > > +the trust status of the process executing the event. > > > > > + > > > > > +In an externally modeled domain, the event type and parameters are > > > > > +exported to userspace for processing by a trust orchestrator with an > > > > > +associated TMA. The trust orchestrator communicates the result of the > > > > > +modeling back to the kernel to support the setting of the process > > > > > +trust status. > > > > > + > > > > > +This model poses a limitation to the ability of TSEM to model some > > > > > +security events. This is secondary to the fact that some event > > > > > +handlers (LSM hooks) are called from a non-sleeping context, as a > > > > > +result the process cannot be scheduled. This is particularly the case > > > > > +with the task based hooks, since they are typically called with the > > > > > +tasklist lock held. > > > > > + > > > > > +This limitation is also inherent to the root model that extends the > > > > > +security state points into TPM PCR 11, secondary to the fact that the > > > > > +process invoking the security event hook will be scheduled away while > > > > > +the TPM transaction completes. > > > > > + > > > > > +Addressing this problem directly requires a consideration of the > > > > > +context from which the security event handlers are being called. > > > > > +Subsequent implementations of TSEM will include a mechanism for > > > > > +asynchronous deferral of model processing, until when and if, a review > > > > > +of the call context would be considered worthwhile by the LSM > > > > > +community. > > > > > > > This is a pretty big limitation, and in conjunction with the some of > > > > the other issues brought up earlier (the PID issue seems the most > > > > concerning), I'm having a difficult time believeing that an external > > > > modeler could operate safely given the design presented here. > > > > > > With respect to the PID issue, we would welcome any comments on the > > > analysis that we provided above as to its design safety. > > > > >From what I can tell from the documentation and our discussion thus > > far is that TSEM relies on a security_task_kill() hook implementation > > to ensure that a process is not killed, and the PID released, without > > explicit TSEM approval. Unfortunately, I believe that relying solely > > on security_task_kill() will not fully cover all of the cases where a > > process can be killed, mostly because security_task_kill() does not > > control process destruction, it controls the ability of one process to > > signal another. > > > You might be able to do something with security_task_free(), but I > > haven't given that much thought. > > Our analysis suggested that an authentication strategy was the > strongest and most complete implementation moving forward. I'll look for that in the next revision. > > > If the PID issue remains a concern, we have an extension to the export > > > descriptions that would include a random nonce that would be emitted > > > with the PID. The nonce would be placed in the LSM task control > > > 'blob' for the sleeping task and used to confirm that the task release > > > directive was acting on the correct process. > > > That should help, but ultimately a nonce is still a bounded resource > > and subject to recycling just like the PID. I'm open to hearing > > other ways in which you believe you can resolve this issue, but I > > remain skeptical. > > FWIW, I believe that current thinking is that a nonce based on a > 64-bit value is immune from recycling. The classic metric for a > 64-bit counter is that a consumption rate of 1000 values/second yields > a counter cycle time of 584,942,417 years. Nanosecond rates still > buys you 584 years. > > I believe that Jason built the Wireguard protocol on this predicate. Once again, just because project X did something doesn't mean it is acceptable here. > We believe the second series will fully address this issue, without > using nonces, for whatever that is worth. We can reserve further > discussion once that code is available and submitted for review. I mentioned this above, but please ensure the authentication approach is well documented. > > > > Frankly, I also wonder how a system would perform with an external > > > > modeler, indepdent of the issues with non-blocking hooks. How does > > > > the system perform with every blockable LSM hook invocation > > > > potentially blocking on a response from userspace? Or with the COE > > > > being somewhat coarse, does the trajectory/policy populate itself > > > > quickly? > > > > > > One obviously experiences a latency hit in going to userspace, by > > > definition, implementing security always has an associated resource > > > cost. So, once again, this comes down to a cost/benefit analysis. > > > > > > As a Gedanken exercise, consider the value proposition of a Linux > > > based RTU, or other device, controlling infrastructure that can only > > > execute security relevant events that are guaranteed to be known good > > > by an external co-processor that is only accessible as a security > > > oracle. > > > > > > Given that frame of reference. > > > > > > Time for a userspace or SGX based TMA transaction is running around > > > 890 micro-seconds. > > > > > > Going to a TMA based in a Xen stubdomain implementation runs a bit > > > longer, probably around 940 micro-seconds or so. > > > > > > The micro-controller implementations are decidedly slower, with the > > > NRF52840-DONGLE clocking in at around 40 micro-seconds, but that is > > > strictly a CPU horsepower issue. > > > > > > All of this with the caveat that we have been focusing almost > > > exclusively on correctness and not optimizing performance. > > > > > > We've thought a bit, mainly on long walks with our Golden Retriever > > > Izzy, about the issue of building a kernel based policy cache with > > > externally modeled domains. Given that the kernel does not, a-priori, > > > know what modeling algorithm a TMA might be using, we would need to > > > come up with a method of deterministically mapping a security event > > > description to a known good state point value. > > > > > > The other issue with all this is that with containerized workloads, > > > particularly micro-services, the rate of security event generation can > > > be surprisingly low. Obviously this is also the case with embedded > > > implementations. > > > > > > Once again, what are you willing to pay to be safe? > > > For better or worse, when code is proposed for the upstream Linux > > Kernel it is subject to scrutiny from all manner of developers and > > users, with most being focused on their own pet projects/subsystems, > > not whatever new security promises you are providing. > > > > There have been patch(sets) and discussions relating to performance > > gains/losses on the other of tens of nanoseconds per operation. > > > > I think most of us in the security community are sympathetic to the > > question of "what are you willing to pay to be safe", but please > > understand that while we are understanding, there are others who will > > disagree not only with the performance cost tradeoff, but the very > > idea of safety you are promising. My only suggestion is to be > > prepared, and be honest with the performance assessments of TSEM. > > We seem to be in agreement that there will always be a natural tension > between security and performance. With TSEM our goal is to offer > choices. > > If an environment is sensitive to performance defects on the order of > tens of nanoseconds, it would seem unlikely that the architects or > administrators of such systems would be implementing integrity > controls of any kind. In that context, we are no different than IMA > or IPE, it would seem highly unlikely that such environments are going > to tolerate a security solution involving a cryptographic checksum of > any type. Performance comparisons are always going to be relative. In the tens-of-nanoseconds example that I'm thinking of, it wasn't about disabling security functionality, it was about optimizing the security functionality. > > > > > +Event handlers that cannot be directly modeled, still consider, on > > > > > +entry, whether or not they are being called by an trusted or untrusted > > > > > +process. As a result, an untrusted process will cause a non-modeled > > > > > +event to return a permissions violation in enforcing mode, even if the > > > > > +security event cannot be directly modeled. > > > > > + > > > > > +Security event modeling typically traps violations of trust by a COE > > > > > +with unmodeled characteristics that is attempting to access/execute a > > > > > +file or map memory as executable; or by a COE with known > > > > > +characteristics attempting to access or execute a CELL not prescribed > > > > > +by a model. As a result, the impact of the ability to not directly > > > > > +model these events is lessened. > > > > > > > > ... > > > > > > > > > +Event modeling > > > > > +-------------- > > > > > + > > > > > +TSEM security event modeling is based on the following functional > > > > > +definition for a security state point: > > > > > + > > > > > +Sp = SHA256(SHA256(EVENT_ID) || TASK_ID || SHA256(COE) || SHA256(CELL)) > > > > > > > It appears that all of the hasing in TSEM is SHA256 based, you might > > > > want to consider making that a Kconfig option at the very least. > > > > > > That has been something that we have talked about as well. > > > > > > As I indicated previously, we really are minimalists, particularly > > > after watching IMA fight with issues surrounding algorithmic agility. > > > > > > It would be easy enough to make this configurable but does anyone see > > > SHA256 as not being useful in in this role anywhere in the next 10 > > > years? > > > There are any number of reasons why one might need to select a > > different hash algorithm: legal constraints, security > > certifications, corporate policy. I would strongly suggest making > > this configurable. > > Certainly sound and well reasoned advice, but the question then becomes > what hashes and what hash lengths, do you have any specific > recommendations? My recommendation is to make it configurable such that as algorithms are added, or removed, from the the kernel crypto code, they can be added to TSEM without much more than some Kconfig changes. > IMA currently has the options of SHA1, SHA256, SHA512, WHIRLPOOL512 > and SM3; is this sufficient coverage, given that SHA1 in a new > implementation like TSEM probably doesn't make any sense? I can't honestly pretend to understand all of the different requirements which would dictate a user's choice of a hash algorithm. About the only thing I can say is that given a choice of stronger options, I wouldn't use SHA1 in a security context on any of the systems I maintain. > Our current inclination, for the initial release, in an embrace of > minimalisim, would be to make this a selectable option when a modeling > domain is setup, with the only selectable option being SHA256. This > would place the onus on userspace to make the decision and doesn't > lock the kernel to an ABI. So long as it is configurable, and the API is designed to support different algorithms, it may be acceptable to only implement one algorithm in the initial implementation. However, one of the easiest ways to ensure the specification and the implementation work correctly would be to support at least two algorithms in the initial implementation so that this ability can be tested.
On Wed, Mar 22, 2023 at 07:45:26PM -0400, Paul Moore wrote: Hi, I hope the week is going well for everyone. > On Mon, Mar 13, 2023 at 6:52???PM Dr. Greg <greg@enjellic.com> wrote: > > On Thu, Mar 02, 2023 at 11:15:56PM -0500, Paul Moore wrote: > > > > Hi Paul, thanks for sending along further comments. > > > > You note below that you haven't had time to look at the code since you > > wanted to confirm the TSEM security model before moving forward. > > > > From a development perspective we are now three weeks into what will > > become version 2 of the patch series. So at this point I wouldn't > > advocate spending a lot of time on the current patchset. > > > > That being said, if you some have time, we would appreciate a quick > > look at the code on your part, with respect to style changes and the > > like we can enforce in the second series, ie. ordering of local > > variable declarations by length and the like. > To be perfectly honest I'm still very concerned about some of the > issues that I've seen in the docs, until that is sorted out I'm not > sure there is much point in looking at the code. I think those concerns can be resolved, see below for more information, the second patch series that we are closing in on should help address the concerns that are currently on the table. That being said, since TSEM is a new codebase, we were hoping that you could give us some guidance on function local variable ordering. Reverse Christmas tree seems popular writ large in the kernel, I believe that you commented in a posting a month or two ago that you prefer standard Christmas tree, SMACK and SeLinux don't seem to religiously embrace a style. Our codebase uses ordering based on least complex to most complex variables and has worked for us, both in the kernel and elsewhere, but we are ambivalent, as our primary objective is to avoid wasting everyone's time on issues such as this. So we would look forward to a recommendation, given that it shouldn't involve wasting any time looking at code. > > > On Tue, Feb 14, 2023 at 6:58???AM Dr. Greg <greg@enjellic.com> wrote: > > > > On Sun, Feb 12, 2023 at 11:33:26PM -0500, Paul Moore wrote: > > > > > On Sat, Feb 4, 2023 at 12:33 AM Dr. Greg <greg@enjellic.com> wrote: > > > > > > > > > > > > An entry was added to the ABI testing documentation to document > > > > > > the files in the TSEM management filesystem. > > > > > > > > > > > > The file documenting the kernel command-line parameters was > > > > > > updated to document the tsem_mode command-line parameter. > > > > > > > > > > > > The primary TSEM documentation file was added to the LSM > > > > > > administration guide and the file was linked to the index of LSM > > > > > > documentation. > > > > > > > > > > > > Signed-off-by: Greg Wettstein <greg@enjellic.com> > > > > > > --- > > > > > > Documentation/ABI/testing/tsemfs | 576 ++++++++ > > > > > > Documentation/admin-guide/LSM/index.rst | 1 + > > > > > > Documentation/admin-guide/LSM/tsem.rst | 1240 +++++++++++++++++ > > > > > > .../admin-guide/kernel-parameters.txt | 5 + > > > > > > 4 files changed, 1822 insertions(+) > > > > > > create mode 100644 Documentation/ABI/testing/tsemfs > > > > > > create mode 100644 Documentation/admin-guide/LSM/tsem.rst > > > > > > > > > One of the more important requirements for any new LSM is that it > > > > > documents a clear, understandable, and reasonable security model along > > > > > with an implementation that faithfully implements that model. Before > > > > > I looked at your code I wanted to try and understand the TSEM security > > > > > model and a few things jumped out at me rather quickly, I imagine > > > > > there would be others as I start to look a bit closer but I wanted to > > > > > send these questions/comments along now to get your take on them ... > > > > > > > > Hi Paul, thanks for taking time to review the documentation and raise > > > > questions, responses below. > > > > > > > > > > diff --git a/Documentation/ABI/testing/tsemfs b/Documentation/ABI/testing/tsemfs > > > > > > new file mode 100644 > > > > > > index 000000000000..3d326934624c > > > > > > --- /dev/null > > > > > > +++ b/Documentation/ABI/testing/tsemfs > > > > > > ... > > > > > > > > > +What: /sys/fs/tsem/measurement > > > > > > +Date: November 2022 > > > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > > > +Description: > > > > > > + The measurement file contains the ASCII base 16 > > > > > > + hexadecimal representation of the 256 bit measurement > > > > > > + value of the security model that the process is > > > > > > + operating in. > > > > > > + > > > > > > + The measurement value is the classic linear extension > > > > > > + measurement of the model. An updated measurement > > > > > > + value is created by extending the current measurement > > > > > > + value with the state coefficient computed for a > > > > > > + security event. > > > > > > + > > > > > > + This measurement value represents a time dependent > > > > > > + measurement of a model and is susceptible to > > > > > > + deviations caused by scheduling differences between > > > > > > + subsequent invocations of a workload. > > > > > > > > > Given the very volatile nature of this value, what is it used for in > > > > > userspace? My apologies if I missed it in the docs. > > > > > > > > It serves the same role as PCR register 10 in IMA, or any other > > > > register in a TPM based architecture using a classic linear extension > > > > mechanism strategy, it can be used to validate a list of time or > > > > sequence ordered measurement values. > > > > > > > > Our personal prejudice is that these types of measurements are of > > > > limited value, which is why we introduce in TSEM, the notion of the > > > > 'state' value for a model, discussed below. > > > > > > > > I would have to go looking on lore for a reference to the exact thread > > > > but Roberto Sassu had offered up a patch set for IMA that addressed > > > > the deficiency of these types of measurements. > > > > > If we all agree that this measurement isn't very useful, and you > > > have implemented an alternative which is intended to address these > > > usability shortcomings, why bother including this measurement in > > > TSEM? > > > > To provide comparable functionality to TPM based security > > architectures, that are currently, considered state of the art for the > > security industry. > > > > As our documentation calls out, TSEM's concept of Trusted Modeling > > Agent's (TMA's), are being proposed to both explore and implement next > > generation hardware assisted security technologies. > > > > Currently, the only measurements that TPM based systems support are > > classic linear extension summing, which I believe we all consider to > > be problematic. > > > > That being said, the 'measurement' value can be used to validate the > > order of the security event execution trajectory. In that role it > > provides the same value that PCR register 10 plays for IMA. > > > > We believe there is a legitimate discussion that can occur, as to > > whether or not this classic attestation architecture is relevant, but > > it seemed appropriate to support it. > > It is relatively easy to add user visible features to the kernel, but > it's almost impossible to remove them. If you see little value in > feature X, to the point that you've developed an alternate mechanism > to avoid the shortcomings which limit the usefulness of X, why include > it? If you later realize that it is important you can always add it. > > Add new functionality to the kernel because it meets a user need, not > simply because "everybody else is doing it". If you've got a defined > use case for this, keep it; however, if you can't define a reasonable > use case I would suggest dropping it and making your life easier. The discussion on this has caused us to implement changes, that will be in V2, that should better justify the measurement value, but see below. > > > It's relatively easy to add features to the Linux Kernel as time > > > goes on, it is *very* difficult to remove them. For this initial > > > submission I would encourage you to implement the bare minimum > > > functionality you need to do something useful and meet your goals. > > > > We can certainly pull the export of the measurement value. In that > > case, would you recommend that we also pull the code that extends the > > security coefficients from the root modeling domain, if a TPM is > > available, into PCR register 11? > > Once again, if you've got a use case, keep it; if not, drop it. Don't > add to the kernel API without a use case. > > > > > > > +What: /sys/fs/tsem/trajectory > > > > > > +Date: November 2022 > > > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > > > +Description: > > > > > > + The trajectory file contains a description of the > > > > > > + security events that have occurred in a security > > > > > > + domain/model. > > > > > > + > > > > > > + Each entry in this file represents a single security > > > > > > + event and consists of brace {} delimited fields that > > > > > > + describe the characteristics of a security event. > > > > > > + Each field has key=value pairs that define > > > > > > + characteristics of the field. > > > > > > + > > > > > > + Each line in a trajectory, or forensics, file will > > > > > > + always have the event{} and COE{} fields. The event > > > > > > + field describes the characteristics of a security > > > > > > + event while the COE field describes the Context Of > > > > > > + Execution that is executing the security event. > > > > > > > > > I think it would be good to provide a concrete definition of > > > > > CELL_DEFINITION field as other areas of the documentation make > > > > > reference to it within the tsem/trajectory file documentation. We can > > > > > somewhat infer it's format, fields, etc. but it's much better to be > > > > > explicit about these things. > > > > > > > > Valid point, we will incorporate a broad definition of what the 'CELL' > > > > represents. > > > > > > > > Conceptually, it is equivalent to the 'object' in mandatory access > > > > controls. In an events based architecture like TSEM, it is > > > > essentially the 'bucket' of values that describe the parameters of a > > > > security event that a COE/process is requesting permission for. > > > > > Yes, I understood conceptually what it represents and what data > > > might be present given a specific operation/rule, but it wasn't > > > clear to me how that data would be represented in the > > > CELL_DEFINITION. > > > > As a bit of further clarification, regarding the security model that > > TSEM is based on. > > > > A TMA extracts the event description parameters, now encoded in > > JSON.. :-), into a structure and then computes a digest value, > > referred to as the 'CELL identity value', over those elements, in > > whatever order the TMA elects to do so in. > > > > Further, a TMA implementation may elect to only include certain > > characteristics in the computation of the CELL identity, depending on > > the model being implemented. > > > > > > > > + The event{} field consists of the following > > > > > > + characteristic definitions: > > > > > > > > > I'm unclear as to the purpose of the event{} field as it is neither > > > > > part of the COE or the CELL, is it here simply to make the event > > > > > easier to read? Or am I misunderstanding things and the event{} > > > > > field is part of the COE? > > > > > > > > It actually serves two roles, one of which, as you note, is to make > > > > the event description easier to read and understand. > > > > > > > > It probably comes as no surprise, but the trust orchestration system > > > > that this is all designed to support, has a security console that can > > > > be used to review the status of all the trust orchestrators that are > > > > supervising security workloads. Either in the cloud, or perhaps, a > > > > large body of edge devices protecting critical infrastructure, if that > > > > doesn't give away too much.... :-) > > > > > > > > Having the process name and executable easily visualized is fairly > > > > useful. > > > > > > > > The second role is to allow the event description records to be > > > > self-describing. The value for the type= key is used by the Trusted > > > > Modeling Agent (TMA) to determine what to look for in the remainder of > > > > the event description record in order to compute the CELL value. > > > > > > > > It also contains the TASK_ID value that ties the security state points > > > > to the integrity of the executable. Since that value is a synthetic > > > > value it was deemed most appropriate to be placed in the event{} > > > > field. > > > > > I think it would be good to provide a more succinct version of the > > > above in the documentation. > > > > We will clarify that. > > > > > > > > + process=COMM > > > > > > + Where COMM is the ASCII representation > > > > > > + of the name of the process executing > > > > > > + the event. > > > > > > + > > > > > > + filename=PATH > > > > > > + If the CELL definition for an event > > > > > > + references a file the filename > > > > > > + characteristic contains a definition > > > > > > + of the path to the file. > > > > > > + > > > > > > + In the case where an event does not > > > > > > + have a file the PATH value is set to a > > > > > > + value of none. > > > > > > > > > What happens in cases where multiple file paths are present in an > > > > > event? Also, given this is visible to userspace, and multiple > > > > > things can affect the path to a file (e.g. namespaces), how is the > > > > > file path determined? > > > > > > > > Unless we have missed something, which is no doubt possible, all of > > > > the security event hooks that we have implemented, which number about > > > > 87 now, that act on a 'file', receive only a single 'struct file *' > > > > pointer as a parameter to the event. > > > > > > > > So we haven't encountered a situation where there would be multiple > > > > files for a single event description. > > > > > I haven't seriously looked at the TSEM sources yet, I'm trying to > > > make sure that I first understand the security model while also > > > ensuring that it is well documented and reasonable. While I can't > > > speak to what LSM hooks TSEM implements, it seems like there are at > > > least a few operations, rename and link come immediately to mind, > > > which would have multiple filenames as part of the operation. How > > > are those operations handled in TSEM, or are they outside the scope > > > of TSEM? > > > > We are currently handling them as generically modeled events so the > > current model treats them as whether or not they occurred. > > > > When they get promoted to explicitly modeled events, the current > > presumption would be to include the involved filenames in the > > description of the event. > Hmmm. > > With the understanding that I didn't go re-read the docs just now, my > gut feeling is that omitting/downgrading events like rename/link/etc. > from the modeling is a pretty significant shortcoming given the > importance of filenames as an identifier in the TSEM events. The fact > that you chose to say "When they get promoted ..." as opposed to "If > they get promited ..." appears to add some credibility to that > thought. > > However, I will be honest and say that I'm not sure I recall the > difference between "generically modeled" and "explicitly modeled" > events in the context of TSEM. Perhaps that would make this clear, > maybe it wouldn't. > > Regardless, can you help me understand why this isn't a concern for > this initial effort and why you've decided to add this later? Least complex answer; minimalism in the initial implementation, which from your previous comments would seem to be a virtue. Slightly more complex; the current models that we are training don't benefit from numerical resolution beyond what is in the initial implementation. Some clarifications that may be useful: Filenames are no more, or no less, important in TSEM than any of the other parameters of the security event basis set. The security relevant entity is the coefficient that gets computed for the event. As the 'Event modeling' section of the TSEM documentation points out, the security coefficient is a functional product of the event, task, COE and CELL identities. Simplisticaly, a generically modeled event operates under the presumption that the security model will only be dependent on whether or not a particular portion of executable memory, executed by a process with defined characteristics, is requesting approval for a specific security event. If the (EVENT:TASK:COE) tuple has not been shown to generate, for example, a filename rename, the event will be denied. If a rename is allowed, and it results in a pathname that has not been included in the model, an attempt to subsequently access the file will also result in a pertubation of the model state. A critical element in all of this is the notion of modeling namespaces that reduce the complexity scope of the implemented models. As an additional, and hopefully helpful example, a micro-services application running in a container may never demonstrate the need to rename or unlink a file. An attempt to do so, if for example the application were compromised, will be denied, regardless of the object of the rename. We have additional work that will be forthcoming on this issue, but as you noted above, and in the last e-mail, better to be simple first. > > > > > > + euid=NN > > > > > > + The ASCII base 10 representation of > > > > > > + the numeric value of the effective > > > > > > + discretionary user id of the process > > > > > > + that is executing the security event. > > > > > > + > > > > > > + euid=NN > > > > > > + The ASCII base 10 representation of > > > > > > + the numeric value of the effective > > > > > > + discretionary user id of the process > > > > > > + that is executing the security event. > > > > > > + > > > > > > + suid=NN > > > > > > + The ASCII base 10 representation of > > > > > > + the numeric value of the saved user id > > > > > > + of the process that is executing the > > > > > > + security event. > > > > > > + > > > > > > + gid=NN > > > > > > + The ASCII base 10 representation of > > > > > > + the numeric value of the discretionary > > > > > > + group id of the process that is > > > > > > + executing the security event. > > > > > > + > > > > > > + egid=NN > > > > > > + The ASCII base 10 representation of > > > > > > + the numeric value of the discretionary > > > > > > + effective group id of the process that > > > > > > + is executing the security event. > > > > > > + > > > > > > + egid=NN > > > > > > + The ASCII base 10 representation of > > > > > > + the numeric value of the discretionary > > > > > > + effective group id of the process that > > > > > > + is executing the security event. > > > > > > + > > > > > > + sgid=NN > > > > > > + The base 10 ASCII representation of > > > > > > + the numeric value of the saved > > > > > > + discretionary group id of the process > > > > > > + that is executing the security event. > > > > > > + > > > > > > + fsuid=NN > > > > > > + The base 10 ASCII representation of > > > > > > + the numeric value of the discretionary > > > > > > + filesystem user id of the process that > > > > > > + is executing the security event. > > > > > > + > > > > > > + fsgid=NN > > > > > > + The ASCII base 10 representation of > > > > > > + the numeric value of the discretionary > > > > > > + filesystem group id of the process > > > > > > + that is executing the security event. > > > > > > + > > > > > > + cap=0xNNN > > > > > > + The ASCII base 16 representation of > > > > > > + the numeric value of effective > > > > > > + capabilities of the process that is > > > > > > + executing the security event. > > > > > > + > > > > > > + If the CELL value for a security event includes the > > > > > > + definition of a file a file{} event field will be > > > > > > + included. The following characteristics will be > > > > > > + encoded in this field: > > > > > > + > > > > > > + flags=NN > > > > > > + The ASCII base 10 representation of > > > > > > + the flags value of the 'struct file' > > > > > > + structure that is the source of the > > > > > > + file description. > > > > > > + > > > > > > + uid=NN > > > > > > + The ASCII base 10 representation of > > > > > > + the discretionary user id of the file. > > > > > > + > > > > > > + gid=NN > > > > > > + The base 10 ASCII representation of > > > > > > + the discretionary group id of the > > > > > > + file. > > > > > > > > > Similar to the task UID/GID mapping questions above, there are > > > > > mechanisms which map the file user/group IDs, which will be used in v> > > > > the CELL definition and how will that be resolved between the kernel > > > > > and an external modeler? > > > > > > > > The answer is the same as with the COE, see the following function: > > > > > > > > security/tsem/event.c:get_file_cell() > > > > > > > > Once again, the TMA only operates on the event description presented > > > > to it and is not influenced by its own namespace. > > > > > For this particular point, my concern isn't what policy the TMA > > > implements, or what it uses as input, it's about understanding how > > > this event information is collected. For fields which can be > > > namespaced (I'm referring to "normal" Linux Kernel namespaces and > > > not any TSEM namespaces), the TSEM documentation should make it > > > clear which namespace is used as a basis for the value. > > > > FWIW, based on feedback we have received, there may be a modeling > > domain/namspace setup option forthcoming that allows a trust > > orchestrator to request that the uid/gid et.al characteristics be > > exported in the context of the current user namespace. > Please make sure you are explicit in which "current user namespace": > the namespace which generated the event, or the namespace in which > the modeling agent is running. You should also provide some > guidance on how to handle issues that might arise when the two > namespaces (generating namespace, modeler namespace) are different. > If you don't plan to allow the modeling agent to run in a separate > namespace from the generating event stream please explain how that > requirement will be enforced by the kernel. We have already validated the implementation for allowing the user namespace reference for a modeling domain to be selected on a domain by domain basis. We will document these issues, FWIW, some clarifications that may be helpful for those following this discussion. For an internally modeled domain, there are no separate entities to be concerned about. The processes that execute in the context of the domain will model their events based on whatever user namespace they are in. If the user namespace changes, the representative characteristics being used will change, which would seem to be reasonable, if the domain has been configured to be sensitive to the user namespace mappings that the process is running in. In an externally modeled domain, by definition, the modeling process must be in a different modeling domain than the modeled process. Our reference to Heisenberg, in the documentation, was not by happenstance, the act of modeling would perturb the state of the modeled system. The modeling process and the modeled processes can run in separate or different user namespaces. The modeling process and the modeled processes will generate and report their derived security state coefficients to different modeling domains. > > > > > > +What: /sys/fs/tsem/ExternalTMA > > > > > > +Date: November 2022 > > > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > > > +Description: > > > > > > + The ExternalTMA directory is a container directory > > > > > > + that hold files that will be used to export the > > > > > > + security events, and their associated parameters, for > > > > > > + externally modeled security domains/namespaces. > > > > > > + > > > > > > + The files created in this directory will be named by > > > > > > + the base 10 ASCII representation of the id value > > > > > > + assigned to the modeling domain/namespace. See the > > > > > > + documentation for the /sys/fs/tsem/id file in this > > > > > > + documentation for more details on this value. > > > > > > + > > > > > > + This file will is a read-only file that can be polled > > > > > > + by a userspace trust orchestration implementation to > > > > > > + process security events that are to be modeled by > > > > > > + an external Trusted Modeling Agent. > > > > > > + > > > > > > + The type of the exported event is the first keyword of > > > > > > + the line that is output and have the following > > > > > > + values and arguments: > > > > > > + > > > > > > + aggregate HEXID: > > > > > > + Where HEXID is the ASCII base 16 > > > > > > + representation of the 256 bit hardware > > > > > > + platform aggregate value. > > > > > > + > > > > > > + export pid{NNN} COE{} CELL_DEFINITION > > > > > > + Where the NNN in the pid field is the ASCII > > > > > > + base 10 value of the id of the process that is > > > > > > + executing the security event that will be > > > > > > + modeled. > > > > > > > > > I worry whenever I see a PID used as an identifier shared across the > > > > > kernel/userspace boundary as it is inherently racy. Given the > > > > > somewhat coarse COE definition where one can expect multiple > > > > > processes/PIDs to share the same COE value, and the ability of > > > > > untrusted users/processes to manipulate the PID table, what do you > > > > > expect to use the pid{NNN} field for in this event? > > > > > > > > > > Similar to the other namespace/mapping issues discussed previously, > > > > > there is also the PID namespace issue to worry about. How is that > > > > > handled here? > > > > > > > > The concern over the PID issue is understandable, I will treat the > > > > reasoning behind its use below. > > > > > > > > The PID value is the 'native' value managed by the kernel, not a > > > > mapped value. > > > > > Regardless of if the PID is rooted in the initial namespace or a > > > different PID namespace, the issue of PIDs being inherently racy is > > > a real problem. Can you help me understand how TSEM avoids the > > > common pitfalls associated with using PIDs to identify processes on > > > the system? > > > > The second version of the TSEM series, now includes support for a > > requirement that a process being externally modeled, authenticate > > itself to the TMA in order for the trust control call to act on > > the process. > Please bear with me, I want to make sure I'm clear on this point. > In order for a process to be modeled by an external > modeling-agent/TMA it would need to first authenticate with the TMA > (using a TBD mechanism); is that correct? Yes, somewhat more specifically, we implemented the requirement for mutual authentication between an external TMA and the modeled process. > I guess we will need to see how the authentication works, but is > there a mechanism in place to ensure that a malicious process could > not pass an authentication token to another (PID recycled) process? If we understand the concern correctly, this would imply that a malicious process has read/write access to arbitrary kernel memory that it is not allowed to access, which would seem to represent a catastrophic security event that cannot be defended against. I think the appropriate metaphor, in classic subject/object security models, would be if a malicious process had the ability to modify either its own or another processes label, i.e if CAP_MAC_ADMIN were lost to an adversary. > Do you plan to support unauthenticated external modeling? If so, > how do you plan to address PID recycling? The current codebase no longer supports anything other than authenticated trust control. > > > > > > +What: /sys/fs/tsem/control > > > > > > +Date: November 2022 > > > > > > +Contact: Greg Wettstein <greg@enjellic.com> > > > > > > +Description: > > > > > > + The control file is the only writable file in the > > > > > > + filesystem and is used by the trust orchestrators to > > > > > > + configure and control the behavior of the TSEM > > > > > > + implementation. > > > > > > + > > > > > > + The following keyword and arguments are recognized: > > > > > > + > > > > > > + internal: > > > > > > + The internal keyword causes an internally > > > > > > + modeled domain to be created for the calling > > > > > > + process. > > > > > > + > > > > > > + external: > > > > > > + The external keyword causes an externally > > > > > > + modeled domain to be created for the calling > > > > > > + process. > > > > > > + > > > > > > + enforce: > > > > > > + The enforce keyword causes the modeling > > > > > > + domain/namespace of the process to enter > > > > > > + enforcing mode. In this mode a value of > > > > > > + -EPERM will be returned for a security event > > > > > > + that does not map into the current set of > > > > > > + allowed state points for the security model > > > > > > + being implemented for the domain/namespace. > > > > > > + > > > > > > + seal: > > > > > > + The seal keyword causes the security model > > > > > > + being implemented for the model to be placed > > > > > > + in sealed state. In this state the current > > > > > > + set of security event points is considered to > > > > > > + be the only set of valid points for the > > > > > > + domain/model. Any subsequent events that map > > > > > > + to a point not in the current model will be > > > > > > + considered a violation of the model. > > > > > > + > > > > > > + trusted PID: > > > > > > + The trusted keyword is used by a trust > > > > > > + orchestrator to indicate that the process > > > > > > + identified by the PID argument should be > > > > > > + allowed to run in trusted status. > > > > > > + > > > > > > + untrusted PID: > > > > > > + The untrusted keyword is used by a trust > > > > > > + orchestrator to indicate that the process > > > > > > + identified by the PID argument should be > > > > > > + allowed to run but designated as an untrusted > > > > > > + process. > > > > > > > > > The 'trusted PID:' and 'untrusted PID:' commands are concerning for > > > > > the reasons described above about PIDs being racy and generally an > > > > > unreliable way of identifying processes across the kernel/userspace > > > > > boundary. I suspect it would not be too difficult for a malicious > > > > > user to trick an external modeler into marking the wrong process as > > > > > trusted/untrusted. > > > > > > > > An external TMA needs the PID value to determine which process to wake > > > > up and set the trust status value on in the task control structure, > > > > after the event is modeled. As was noted above, the PID value is the > > > > unmapped value maintained by the OS. > > > > > > > > Lets see if we can reason through why the PID can be used safely. > > > > > > > > CAP_TRUST, or whatever ends up getting used, is required by the trust > > > > orchestrator to create a security/modeling namespace for the workload > > > > being modeled. This results in the creation of the following > > > > pseudo-file for surfacing the security event descriptions for the > > > > namespace/workload: > > > > > > > > /sys/fs/tsem/ExternalTMA/N > > > > > > > > Where N is the id number of the modeling domain. > > > > > > > > CAP_TRUST, caveats applied, is required to open the pseudo-file. The > > > > trust orchestrator only receives and acts on PID values through this > > > > conduit from the kernel. > > > > > > > > When an event description is exported, the trust status of the task is > > > > set to 'pending' and the process is placed in interruptible sleep and > > > > scheduled away, with the 'wakeup' criteria being the trust status > > > > being changed from pending to either trusted or untrusted. > > > > > > > > The only path to change the trust status value in the LSM task control > > > > structure and wake up the process is by the trust orchestrator that > > > > created the namespace, by writing the appropriate value to the > > > > /sys/fs/tsem/control file. Access to that file is gated by CAP_TRUST > > > > or its equivalent. > > > > > > > > See the following code locations for further details: > > > > > > > > security/tsem/export.c:tsem_export_event() > > > > > > > > security/tsem/fs.c:control_COE() > > > > > > > > As long as the process 'exists', albeit sleeping, the PID slot is > > > > occupied and an adversary, regardless of namespace, cannot substitute > > > > a task with the same PID value. > > > > > > > > This leaves an adversary with the need to terminate the task being > > > > modeled in order to capture its PID slot. > > > > > > > > Precautions are implemented in the following function to protect the > > > > process from being terminated by an adversary: > > > > > > > > security/tsem/tsem.c:tsem_task_kill() > > > > > What about the OOM killer? > > > > > > The security_task_kill() LSM hook only offers an access control point > > > for one process sending another process a signal, it doesn't gate a > > > process being killed for other reasons. The OOM killer is the first > > > thing that comes to mind, but I'm reasonably certain there are other > > > similar scenarios. > > > > As noted above, as an additional protection, the next version of the > > series requires that a process authenticate itself as being a member > > of the modeling domain in order for the trust status control call to > > succeed. > > > > With this implementation, substituting an alternate process would now > > require that an adversary break the security context between the TMA > > and process in the modeling domain. > I'll look forward to seeing the new authentication mechanism. Please > ensure it is properly documented. The full details will be there. > > > > > > +Process and Platform Trust Status > > > > > > +================================= > > > > > > + > > > > > > +A fundamental concept in TSEM is the notion of providing a precise > > > > > > +definition for what it means for a platform or workload to be trusted. > > > > > > +A trusted platform or workload is one where there has not been an > > > > > > +attempt by a process to execute a security relevant event that does > > > > > > +not map into a known security state point. > > > > > > + > > > > > > +The process trust status is a characteristic of the process that is > > > > > > +passed to any subordinate processes that are descendants of that > > > > > > +process. Once a process is tagged as untrusted, that characteristic > > > > > > +cannot be removed from the process. In a 'fruit from the poisoned > > > > > > +vine' paradigm, all subordinate processes created by an untrusted > > > > > > +process are untrusted as well. > > > > > > + > > > > > > +On entry into each TSEM security event handler, the trust status of a > > > > > > +process is checked before an attempt to model the event is made. An > > > > > > +attempt to execute a security event by an untrusted process will cause > > > > > > +the event, and its characteristics, to be logged. The return status > > > > > > +of the hook will be determined by the enforcement state of the model. > > > > > > +A permission denial is only returned if the TMA is running in > > > > > > +enforcing mode. > > > > > > + > > > > > > +If the platform running the TSEM LSM has a TPM, the hardware aggregate > > > > > > +value is computed at the time that TSEM is initialized. This hardware > > > > > > +aggregate value is the linear extension sum over Platform > > > > > > +Configuration Registers (PCR's) 0 through 7. This is the same > > > > > > +aggregate value that is computed by the Integrity Measurement > > > > > > +Architecture (IMA) and is the industry standard method of providing an > > > > > > +evaluation measurement of the hardware platform state. > > > > > > + > > > > > > +Internally model domains have the hardware aggregate measurement > > > > > > +included as the first state point in the security model. Externally > > > > > > +modeled domains export the hardware aggregate value to the TMA for > > > > > > +inclusion as the first state point of the model maintained by the TMA. > > > > > > + > > > > > > +The root modeling domain extends each security state point into PCR > > > > > > +11. This allows hardware based TSEM measurements to coexist with IMA > > > > > > +measurement values. This hardware measurement value can be used to > > > > > > +attest to the security execution trajectory that the root model > > > > > > +maintains. > > > > > > > > > It seems like making the target PCR configurable would be a good > > > > > idea, at the very least make it a Kconfig option. > > > > > > > > That was something that we have thought about, it probably needs a > > > > Kconfig option. > > > > > > > > Contrary to all appearances, as a team we are really minimalists at > > > > heart and tend to not make things more complex or configurable than > > > > needed.... :-) > > > > > > > > > Also, can you elaborate on how the security state points are > > > > > extended into the PCR? I imagine for it to be useful at an > > > > > arbitrary point in time this would require the PCR to be extended as > > > > > the security points were generated, which would imply that the PCR > > > > > value would be dependent on execution order, and in most cases, > > > > > scheduling order as well. How useful do you expect this to be for > > > > > most users? > > > > > > > > Your assessment is correct, the state points are extended into the PCR > > > > whenever a unique security state point is generated. > > > > > > > > In a 'free-running' model, the value in the register will be fungible > > > > due to scheduling dependencies. > > > > > In other words, garbage ;) > > > > We don't disagree on the utility of a scheduling fungible measurement > > value. However, this is an remarkably interesting > > conclusion/statement, by the Linux security sub-system maintainer no > > less, given that it describes the current state of the art with > > respect to hardware security co-processors and trusted system > > technology.. :-) > I've yet to meet a kernel maintainer that doesn't hold amusing > opinions on at least one issue; one could almost make an argument that > it is a prerequisite for the role. However, I feel that using > non-deterministic values as a measure of system state/attestation is > well understood to be garbage and isn't quite as interesting as you > would make it. > > Based on the rest of the TSEM docs and this discussion, I'm guessing > you are referencing IMA's measurements into PCR 10, or something > similar, when you talk about the current state of the art, is that > correct? Yes. > In the case of IMA, the important thing to remember is that PCR 10 > can be reliably attested using the IMA measurement log; the IMA > project even provides tools and documentation demonstrating how to > do so. Does TSEM offer a similar measurement log? Yes, in TSEM, the 'measurement' value can be used to validate the order that the security state coefficients, ie. the values surfaced in the /sys/kernel/security/tsem/points pseudo-file, were generated in. > My apologies if I missed it. I always tell people that all of this is straight forward, but there is probably a lot here. > > > > If the model is pre-defined, the security state points will be > > > > extended into the register as they are loaded through the > > > > /sys/fs/tsem/map pseudo-file interface. In this case, the value will > > > > be fixed and any departure from the value would signal that the > > > > modeling domain has departed from its specification. > > > > > > > > With respect to the utility of the value, in a 'free-running' model it > > > > is about as useful as the value that IMA maintains in PCR 10, which in > > > > our opinion is not very useful and is why we implemented the notion of > > > > the 'state' value of a model. > > > > > For a variety of reasons, and mostly to help keep things civil, > > > let's refrain from comparing one LSM to another. Each LSM makes its > > > own choices, and needs to stand on its own; just because LSM did X > > > doesn't mean TSEM can do X if it is silly in the context of TSEM. > > > > Our intent was not to be incivil, but rather to call out one of the > > motivations in the implementation of TSEM, and in a larger context, > > the notion of a TMA based security architecture. > > > > A now prehistoric version of TSEM was implemented as a patch on top of > > IMA. We actually built systems for clients on top of that > > architecture. Our concept of a 'state' value was driven by the > > difficulties we experienced in implementing, and maintaining, these > > systems in a field environment. > > > > We offer the concept of a 'state' value in order to simplify the > > attestation model, which classically, has required that a verifying > > party review an event log for its validity, after verifying that the > > measurement value confirms the integrity of the log. > Having a log ordered by the sequence of events can be important. > After all, if a security critical configuration knob is toggled > multiple times, and the event ordering is not preserved, how does one > know the current state of the system? I might be able to see that the > knob was turned both on and off, but without knowing which occurred > last, how do I know if the system is in a known good state? Yes, that is classically the explanation that is given for having an ordered event log. That being said, we tend to struggle with the validity of this thinking, that is not criticism, perhaps more of a lack of understanding on our part. Let's consider IMA, or TSEM running in a model context that only observes the integrity of binaries run with root privileges, roughly equivalent implementations. In either scenario, you have an attestation of the fact that a known binary executed in a known temporal order, but does that tell you the final state of the system from a security perspective? Take iptables as an example, given its potential contribution to the trust status of a system. If you know that it executed twice, can it be effectively reasoned what it was doing each time it executed, without access to things like the command-line arguments? Conceptually, in an extremely static system configuration, the rule might be that system attestation fails if iptables ran more than once, but in a multi-execution scenario it is unclear what can be reasoned. > > > > > > +Internal vs external modeling > > > > > > +----------------------------- > > > > > > + > > > > > > +When a TSEM modeling domain is created, a designation is made as to > > > > > > +whether the domain is to be internally or externally modeled. > > > > > > + > > > > > > +In an internally modeled domain, the security event handlers pass the > > > > > > +event type and its characteristics to the designated internal trusted > > > > > > +modeling agent. The agent provides the permission value for the > > > > > > +security event handler to return as the result of the event and sets > > > > > > +the trust status of the process executing the event. > > > > > > + > > > > > > +In an externally modeled domain, the event type and parameters are > > > > > > +exported to userspace for processing by a trust orchestrator with an > > > > > > +associated TMA. The trust orchestrator communicates the result of the > > > > > > +modeling back to the kernel to support the setting of the process > > > > > > +trust status. > > > > > > + > > > > > > +This model poses a limitation to the ability of TSEM to model some > > > > > > +security events. This is secondary to the fact that some event > > > > > > +handlers (LSM hooks) are called from a non-sleeping context, as a > > > > > > +result the process cannot be scheduled. This is particularly the case > > > > > > +with the task based hooks, since they are typically called with the > > > > > > +tasklist lock held. > > > > > > + > > > > > > +This limitation is also inherent to the root model that extends the > > > > > > +security state points into TPM PCR 11, secondary to the fact that the > > > > > > +process invoking the security event hook will be scheduled away while > > > > > > +the TPM transaction completes. > > > > > > + > > > > > > +Addressing this problem directly requires a consideration of the > > > > > > +context from which the security event handlers are being called. > > > > > > +Subsequent implementations of TSEM will include a mechanism for > > > > > > +asynchronous deferral of model processing, until when and if, a review > > > > > > +of the call context would be considered worthwhile by the LSM > > > > > > +community. > > > > > > > > > This is a pretty big limitation, and in conjunction with the some of > > > > > the other issues brought up earlier (the PID issue seems the most > > > > > concerning), I'm having a difficult time believeing that an external > > > > > modeler could operate safely given the design presented here. > > > > > > > > With respect to the PID issue, we would welcome any comments on the > > > > analysis that we provided above as to its design safety. > > > > > > >From what I can tell from the documentation and our discussion thus > > > far is that TSEM relies on a security_task_kill() hook implementation > > > to ensure that a process is not killed, and the PID released, without > > > explicit TSEM approval. Unfortunately, I believe that relying solely > > > on security_task_kill() will not fully cover all of the cases where a > > > process can be killed, mostly because security_task_kill() does not > > > control process destruction, it controls the ability of one process to > > > signal another. > > > > > You might be able to do something with security_task_free(), but I > > > haven't given that much thought. > > > > Our analysis suggested that an authentication strategy was the > > strongest and most complete implementation moving forward. > > I'll look for that in the next revision. > > > > > If the PID issue remains a concern, we have an extension to the export > > > > descriptions that would include a random nonce that would be emitted > > > > with the PID. The nonce would be placed in the LSM task control > > > > 'blob' for the sleeping task and used to confirm that the task release > > > > directive was acting on the correct process. > > > > > That should help, but ultimately a nonce is still a bounded resource > > > and subject to recycling just like the PID. I'm open to hearing > > > other ways in which you believe you can resolve this issue, but I > > > remain skeptical. > > > > FWIW, I believe that current thinking is that a nonce based on a > > 64-bit value is immune from recycling. The classic metric for a > > 64-bit counter is that a consumption rate of 1000 values/second yields > > a counter cycle time of 584,942,417 years. Nanosecond rates still > > buys you 584 years. > > > > I believe that Jason built the Wireguard protocol on this predicate. > Once again, just because project X did something doesn't mean it is > acceptable here. FWIW, from a design perspective, we try to operate under the assumption that there are well understood architectural predicates that secure systems can be built on. For example, the statistical infeasibility of predicting a large number generated by a random number generator with known numerical characteristics or the lack of a direct solution to the discrete logarithm problem. We bin the chronological infeasibility of wrapping a 64-bit counter in the same bucket, perhaps that is an oversight on our part. > > We believe the second series will fully address this issue, without > > using nonces, for whatever that is worth. We can reserve further > > discussion once that code is available and submitted for review. > I mentioned this above, but please ensure the authentication approach > is well documented. It will be explained in detail. > > > > > Frankly, I also wonder how a system would perform with an external > > > > > modeler, indepdent of the issues with non-blocking hooks. How does > > > > > the system perform with every blockable LSM hook invocation > > > > > potentially blocking on a response from userspace? Or with the COE > > > > > being somewhat coarse, does the trajectory/policy populate itself > > > > > quickly? > > > > > > > > One obviously experiences a latency hit in going to userspace, by > > > > definition, implementing security always has an associated resource > > > > cost. So, once again, this comes down to a cost/benefit analysis. > > > > > > > > As a Gedanken exercise, consider the value proposition of a Linux > > > > based RTU, or other device, controlling infrastructure that can only > > > > execute security relevant events that are guaranteed to be known good > > > > by an external co-processor that is only accessible as a security > > > > oracle. > > > > > > > > Given that frame of reference. > > > > > > > > Time for a userspace or SGX based TMA transaction is running around > > > > 890 micro-seconds. > > > > > > > > Going to a TMA based in a Xen stubdomain implementation runs a bit > > > > longer, probably around 940 micro-seconds or so. > > > > > > > > The micro-controller implementations are decidedly slower, with the > > > > NRF52840-DONGLE clocking in at around 40 micro-seconds, but that is > > > > strictly a CPU horsepower issue. > > > > > > > > All of this with the caveat that we have been focusing almost > > > > exclusively on correctness and not optimizing performance. > > > > > > > > We've thought a bit, mainly on long walks with our Golden Retriever > > > > Izzy, about the issue of building a kernel based policy cache with > > > > externally modeled domains. Given that the kernel does not, a-priori, > > > > know what modeling algorithm a TMA might be using, we would need to > > > > come up with a method of deterministically mapping a security event > > > > description to a known good state point value. > > > > > > > > The other issue with all this is that with containerized workloads, > > > > particularly micro-services, the rate of security event generation can > > > > be surprisingly low. Obviously this is also the case with embedded > > > > implementations. > > > > > > > > Once again, what are you willing to pay to be safe? > > > > > For better or worse, when code is proposed for the upstream Linux > > > Kernel it is subject to scrutiny from all manner of developers and > > > users, with most being focused on their own pet projects/subsystems, > > > not whatever new security promises you are providing. > > > > > > There have been patch(sets) and discussions relating to performance > > > gains/losses on the other of tens of nanoseconds per operation. > > > > > > I think most of us in the security community are sympathetic to the > > > question of "what are you willing to pay to be safe", but please > > > understand that while we are understanding, there are others who will > > > disagree not only with the performance cost tradeoff, but the very > > > idea of safety you are promising. My only suggestion is to be > > > prepared, and be honest with the performance assessments of TSEM. > > > > We seem to be in agreement that there will always be a natural tension > > between security and performance. With TSEM our goal is to offer > > choices. > > > > If an environment is sensitive to performance defects on the order of > > tens of nanoseconds, it would seem unlikely that the architects or > > administrators of such systems would be implementing integrity > > controls of any kind. In that context, we are no different than IMA > > or IPE, it would seem highly unlikely that such environments are going > > to tolerate a security solution involving a cryptographic checksum of > > any type. > Performance comparisons are always going to be relative. In the > tens-of-nanoseconds example that I'm thinking of, it wasn't about > disabling security functionality, it was about optimizing the > security functionality. Given the current performance hit that speculative execution has given us, with respect to indirect function calls, it would seem that the LSM is going to be a problematic architecture, particularly with any type of stacking.... :-) > > > > > > +Event handlers that cannot be directly modeled, still consider, on > > > > > > +entry, whether or not they are being called by an trusted or untrusted > > > > > > +process. As a result, an untrusted process will cause a non-modeled > > > > > > +event to return a permissions violation in enforcing mode, even if the > > > > > > +security event cannot be directly modeled. > > > > > > + > > > > > > +Security event modeling typically traps violations of trust by a COE > > > > > > +with unmodeled characteristics that is attempting to access/execute a > > > > > > +file or map memory as executable; or by a COE with known > > > > > > +characteristics attempting to access or execute a CELL not prescribed > > > > > > +by a model. As a result, the impact of the ability to not directly > > > > > > +model these events is lessened. > > > > > > > > > > ... > > > > > > > > > > > +Event modeling > > > > > > +-------------- > > > > > > + > > > > > > +TSEM security event modeling is based on the following functional > > > > > > +definition for a security state point: > > > > > > + > > > > > > +Sp = SHA256(SHA256(EVENT_ID) || TASK_ID || SHA256(COE) || SHA256(CELL)) > > > > > > > > > It appears that all of the hasing in TSEM is SHA256 based, you might > > > > > want to consider making that a Kconfig option at the very least. > > > > > > > > That has been something that we have talked about as well. > > > > > > > > As I indicated previously, we really are minimalists, particularly > > > > after watching IMA fight with issues surrounding algorithmic agility. > > > > > > > > It would be easy enough to make this configurable but does anyone see > > > > SHA256 as not being useful in in this role anywhere in the next 10 > > > > years? > > > > > There are any number of reasons why one might need to select a > > > different hash algorithm: legal constraints, security > > > certifications, corporate policy. I would strongly suggest making > > > this configurable. > > > > Certainly sound and well reasoned advice, but the question then becomes > > what hashes and what hash lengths, do you have any specific > > recommendations? > My recommendation is to make it configurable such that as algorithms > are added, or removed, from the the kernel crypto code, they can be > added to TSEM without much more than some Kconfig changes. TSEM/V2 now can use any hash function that a kernel has available, it was actually a remarkably straight forward implementation. > > IMA currently has the options of SHA1, SHA256, SHA512, WHIRLPOOL512 > > and SM3; is this sufficient coverage, given that SHA1 in a new > > implementation like TSEM probably doesn't make any sense? > I can't honestly pretend to understand all of the different > requirements which would dictate a user's choice of a hash algorithm. > About the only thing I can say is that given a choice of stronger > options, I wouldn't use SHA1 in a security context on any of the > systems I maintain. Nor would we, but it is now available if anyone wants it.... :-) > > Our current inclination, for the initial release, in an embrace of > > minimalisim, would be to make this a selectable option when a modeling > > domain is setup, with the only selectable option being SHA256. This > > would place the onus on userspace to make the decision and doesn't > > lock the kernel to an ABI. > So long as it is configurable, and the API is designed to support > different algorithms, it may be acceptable to only implement one > algorithm in the initial implementation. However, one of the easiest > ways to ensure the specification and the implementation work correctly > would be to support at least two algorithms in the initial > implementation so that this ability can be tested. We are now validating against multiple hash implementations, each with multiple digest sizes, so hopefully this will lay the cryptographic agility issue to rest. > paul-moore.com FWIW, we do appreciate your perspective on these issues, the implementation has already improved as a result of your concerns. Have a good remainder of the week. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity
On Wed, Mar 29, 2023 at 11:35 PM Dr. Greg <greg@enjellic.com> wrote: > On Wed, Mar 22, 2023 at 07:45:26PM -0400, Paul Moore wrote: > > On Mon, Mar 13, 2023 at 6:52???PM Dr. Greg <greg@enjellic.com> wrote: > > > On Thu, Mar 02, 2023 at 11:15:56PM -0500, Paul Moore wrote: > > > > > > Hi Paul, thanks for sending along further comments. > > > > > > You note below that you haven't had time to look at the code since you > > > wanted to confirm the TSEM security model before moving forward. > > > > > > From a development perspective we are now three weeks into what will > > > become version 2 of the patch series. So at this point I wouldn't > > > advocate spending a lot of time on the current patchset. > > > > > > That being said, if you some have time, we would appreciate a quick > > > look at the code on your part, with respect to style changes and the > > > like we can enforce in the second series, ie. ordering of local > > > variable declarations by length and the like. > > > To be perfectly honest I'm still very concerned about some of the > > issues that I've seen in the docs, until that is sorted out I'm not > > sure there is much point in looking at the code. > > I think those concerns can be resolved, see below for more > information, the second patch series that we are closing in on should > help address the concerns that are currently on the table. In that case, I think it might be best to wrap up this thread and we can resume the discussion on the next patchset. > That being said, since TSEM is a new codebase, we were hoping that you > could give us some guidance on function local variable ordering. > Reverse Christmas tree seems popular writ large in the kernel, I > believe that you commented in a posting a month or two ago that you > prefer standard Christmas tree, SMACK and SeLinux don't seem to > religiously embrace a style. > > Our codebase uses ordering based on least complex to most complex > variables and has worked for us, both in the kernel and elsewhere, but > we are ambivalent, as our primary objective is to avoid wasting > everyone's time on issues such as this. The canonical guidance on coding style within the kernel is in the kernel docs: https://www.kernel.org/doc/html/latest/process/coding-style.html When in doubt, I would recommend following that as closely as possible. As far as local variable ordering is concerned, I don't believe I've ever rejected patches due to that. My own personal preference usually follows what you've described above: the least complex (simple scalars) at the top, with the more complex variables (composites) at the bottom. In practice this tends to result in a "Christmas Tree" ordering, but it can be a bit lumpy (?) in some cases; that is fine. There are two style nitpicks which annoy me enough to make it worth mentioning: * Stick to 80 characters as much as possible, yes we all have terminals that can go wider, but I like to have several terminals on my screen and if they all need to be 100 chars wide I can't fit as many. There are going to be some exceptions, e.g. error message string literals, but that should only happen a few times in a given file. If you are finding that every function you write has a line that goes past 80 characters you are doing *something* wrong. * If/when you split a single line across multiple lines due to the above, make sure the lines are indented properly such that they line up properly with the code above. It's tricky to give all of the different examples so I'm not going to even try. I realize that is garbage guidance, but the kernel coding style is a help here. If you are really lost, I use the following 'astyle' command in other projects, and it should produce fairly kernel-style friendly code: % astyle --options=none --lineend=linux --mode=c \ --style=linux \ --indent=force-tab=8 \ --indent-preprocessor \ --indent-col1-comments \ --min-conditional-indent=0 \ --max-instatement-indent=80 \ --pad-oper \ --align-pointer=name \ --align-reference=name \ --max-code-length=80 \ --break-after-logical
On Wed, Apr 05, 2023 at 04:45:26PM -0400, Paul Moore wrote: Good morning, I hope the week has gone well for everyone. > On Wed, Mar 29, 2023 at 11:35???PM Dr. Greg <greg@enjellic.com> wrote: > > On Wed, Mar 22, 2023 at 07:45:26PM -0400, Paul Moore wrote: > > > On Mon, Mar 13, 2023 at 6:52???PM Dr. Greg <greg@enjellic.com> wrote: > > > > On Thu, Mar 02, 2023 at 11:15:56PM -0500, Paul Moore wrote: > > > > > > > > Hi Paul, thanks for sending along further comments. > > > > > > > > You note below that you haven't had time to look at the code since you > > > > wanted to confirm the TSEM security model before moving forward. > > > > > > > > From a development perspective we are now three weeks into what will > > > > become version 2 of the patch series. So at this point I wouldn't > > > > advocate spending a lot of time on the current patchset. > > > > > > > > That being said, if you some have time, we would appreciate a quick > > > > look at the code on your part, with respect to style changes and the > > > > like we can enforce in the second series, ie. ordering of local > > > > variable declarations by length and the like. > > > > > To be perfectly honest I'm still very concerned about some of the > > > issues that I've seen in the docs, until that is sorted out I'm not > > > sure there is much point in looking at the code. > > > > I think those concerns can be resolved, see below for more > > information, the second patch series that we are closing in on should > > help address the concerns that are currently on the table. > In that case, I think it might be best to wrap up this thread and we > can resume the discussion on the next patchset. Very good, we will look forward to the review of V2, which has now been enhanced on a number of fronts. > > That being said, since TSEM is a new codebase, we were hoping that you > > could give us some guidance on function local variable ordering. > > Reverse Christmas tree seems popular writ large in the kernel, I > > believe that you commented in a posting a month or two ago that you > > prefer standard Christmas tree, SMACK and SeLinux don't seem to > > religiously embrace a style. > > > > Our codebase uses ordering based on least complex to most complex > > variables and has worked for us, both in the kernel and elsewhere, but > > we are ambivalent, as our primary objective is to avoid wasting > > everyone's time on issues such as this. > > The canonical guidance on coding style within the kernel is in the kernel docs: > > https://www.kernel.org/doc/html/latest/process/coding-style.html > > When in doubt, I would recommend following that as closely as possible. > > As far as local variable ordering is concerned, I don't believe I've > ever rejected patches due to that. My own personal preference usually > follows what you've described above: the least complex (simple > scalars) at the top, with the more complex variables (composites) at > the bottom. In practice this tends to result in a "Christmas Tree" > ordering, but it can be a bit lumpy (?) in some cases; that is fine. > > There are two style nitpicks which annoy me enough to make it worth mentioning: > > * Stick to 80 characters as much as possible, yes we all have > terminals that can go wider, but I like to have several terminals on > my screen and if they all need to be 100 chars wide I can't fit as > many. There are going to be some exceptions, e.g. error message > string literals, but that should only happen a few times in a given > file. If you are finding that every function you write has a line > that goes past 80 characters you are doing *something* wrong. > > * If/when you split a single line across multiple lines due to the > above, make sure the > lines are indented properly such that they line up properly with the > code above. It's tricky to give all of the different examples so I'm > not going to even try. I realize that is garbage guidance, but the > kernel coding style is a help here. > > If you are really lost, I use the following 'astyle' command in other > projects, and it should produce fairly kernel-style friendly code: > > % astyle --options=none --lineend=linux --mode=c \ > --style=linux \ > --indent=force-tab=8 \ > --indent-preprocessor \ > --indent-col1-comments \ > --min-conditional-indent=0 \ > --max-instatement-indent=80 \ > --pad-oper \ > --align-pointer=name \ > --align-reference=name \ > --max-code-length=80 \ > --break-after-logical All of the above is consistent with what we have used for years, particularly 80 columns, given that the principles of TSEM extend from programming with a Model 29 keypunch and a drum card to applying machine learning to security. > paul-moore.com Have a good weekend. As always, Dr. Greg The Quixote Project - Flailing at the Travails of Cybersecurity
diff --git a/Documentation/ABI/testing/tsemfs b/Documentation/ABI/testing/tsemfs new file mode 100644 index 000000000000..3d326934624c --- /dev/null +++ b/Documentation/ABI/testing/tsemfs @@ -0,0 +1,576 @@ +What: /sys/fs/tsem +Date: November 2022 +Contact: Greg Wettstein <greg@enjellic.com> +Description: + The /sys/fs/tsem directory contains files and one + directory that implement the control plane for the + Trusted Security Event Modeling (TSEM) LSM. + + The files in this directory, with the exception of the + aggregate file, when read, reflect the values for the + modeling domain/namespace that the process reading the + files is operating in. + +What: /sys/fs/tsem/aggregate +Date: November 2022 +Contact: Greg Wettstein <greg@enjellic.com> +Description: + The aggregate file contains the ASCII base 16 + representation of the 256 bit hardware platform + aggregate that TSEM is modeling under. The platform + aggregate is the extension measurement of the Trusted + Platform Module PCR registers 0 through 8. + +What: /sys/fs/tsem/forensics +Date: November 2022 +Contact: Greg Wettstein <greg@enjellic.com> +Description: + The forensics file contains the descriptions of + security events that are inconsistent with the + security model that the domain/namespace is running + under. Forensics events are generated after a + security model is 'sealed' and the events represent + security state points that have not already been + defined in the model. + + The format of lines in this file are identical to the + output generated by the /sys/fs/tsem/trajectory file + that is documented below. + +What: /sys/fs/tsem/id +Date: November 2022 +Contact: Greg Wettstein <greg@enjellic.com> +Description: + The id file contains the ASCII base 10 representation + of the model domain/namespace identifier that the + reading process is operating in. + + The root domain/namespace has a value of zero, with a + non-zero value representing a modeling domain + independent from the root model. + + A domain with a non-zero id value, that is externally + modeled. Each externally modeled domain will have a + file created in the /sys/fs/tsem/ExternalTMA directory + that is documented at the end of this document. + +What: /sys/fs/tsem/measurement +Date: November 2022 +Contact: Greg Wettstein <greg@enjellic.com> +Description: + The measurement file contains the ASCII base 16 + hexadecimal representation of the 256 bit measurement + value of the security model that the process is + operating in. + + The measurement value is the classic linear extension + measurement of the model. An updated measurement + value is created by extending the current measurement + value with the state coefficient computed for a + security event. + + This measurement value represents a time dependent + measurement of a model and is susceptible to + deviations caused by scheduling differences between + subsequent invocations of a workload. + +What: /sys/fs/tsem/points +Date: November 2022 +Contact: Greg Wettstein <greg@enjellic.com> +Description: + The points file contains the ASCII base 16 + representation of the 256 bit security state points of + a security domain/model. The number of entries in + this file represent the number of security events that + are represented by the model. + +What: /sys/fs/tsem/state +Date: November 2022 +Contact: Greg Wettstein <greg@enjellic.com> +Description: + The state file contains the ASCII base 16 + representation of the 256 bit value of the functional + state of a security domain/model. + + The state value is a time independent representation + of the measurement of a model/domain, and unlike the + measurement value, is a time independent + representation of the security state of a workload. + + This value is designed to be a single value that can + be attested to represent whether or not a workload has + deviated from a defined security behavior. + +What: /sys/fs/tsem/trajectory +Date: November 2022 +Contact: Greg Wettstein <greg@enjellic.com> +Description: + The trajectory file contains a description of the + security events that have occurred in a security + domain/model. + + Each entry in this file represents a single security + event and consists of brace {} delimited fields that + describe the characteristics of a security event. + Each field has key=value pairs that define + characteristics of the field. + + Each line in a trajectory, or forensics, file will + always have the event{} and COE{} fields. The event + field describes the characteristics of a security + event while the COE field describes the Context Of + Execution that is executing the security event. + + The event{} field consists of the following + characteristic definitions: + + process=COMM + Where COMM is the ASCII representation + of the name of the process executing + the event. + + filename=PATH + If the CELL definition for an event + references a file the filename + characteristic contains a definition + of the path to the file. + + In the case where an event does not + have a file the PATH value is set to a + value of none. + + type=EVENT_TYPE + The value field for a type key is the + name of the security event that is + being modeled. The list of value + EVENT_TYPE names is defined in the + following source file: + + security/tsem/tsem.c + + If the security event is a generically + modeled event the EVENT_TYPE will be + generic_event. In this case the CELL + characteristics for the event will be + described by a generic_event{} field. + + task_id=TASK_ID + The value of the task_id key will the + ASCII base 16 representation of the + model identity of the task that is + executing the security event. + + The following documentation file: + + Documentation/admin-guide/LSM/TSEM.rst + + Describes how the TASK_ID value is + generated. + + The COE{} field consists of the following + characteristic definitions: + + uid=NN + The ASCII base 10 representation of + the numeric value of the discretionary + user id of the process that is + executing the security event. + + euid=NN + The ASCII base 10 representation of + the numeric value of the effective + discretionary user id of the process + that is executing the security event. + + euid=NN + The ASCII base 10 representation of + the numeric value of the effective + discretionary user id of the process + that is executing the security event. + + suid=NN + The ASCII base 10 representation of + the numeric value of the saved user id + of the process that is executing the + security event. + + gid=NN + The ASCII base 10 representation of + the numeric value of the discretionary + group id of the process that is + executing the security event. + + egid=NN + The ASCII base 10 representation of + the numeric value of the discretionary + effective group id of the process that + is executing the security event. + + egid=NN + The ASCII base 10 representation of + the numeric value of the discretionary + effective group id of the process that + is executing the security event. + + sgid=NN + The base 10 ASCII representation of + the numeric value of the saved + discretionary group id of the process + that is executing the security event. + + fsuid=NN + The base 10 ASCII representation of + the numeric value of the discretionary + filesystem user id of the process that + is executing the security event. + + fsgid=NN + The ASCII base 10 representation of + the numeric value of the discretionary + filesystem group id of the process + that is executing the security event. + + cap=0xNNN + The ASCII base 16 representation of + the numeric value of effective + capabilities of the process that is + executing the security event. + + If the CELL value for a security event includes the + definition of a file a file{} event field will be + included. The following characteristics will be + encoded in this field: + + flags=NN + The ASCII base 10 representation of + the flags value of the 'struct file' + structure that is the source of the + file description. + + uid=NN + The ASCII base 10 representation of + the discretionary user id of the file. + + gid=NN + The base 10 ASCII representation of + the discretionary group id of the + file. + + mode=0NNN + The ASCII base 8 representation of the + mode bits of the file. + + name_length=NN + The ASCII base 10 representation of + the length of the pathname that will + be encoded in the name= characteristic. + + name=NN + The ASCII hexadecimal representation + of the SHA256 checksum of the pathname + of the file that is pre-pended with + the little-endian binary value of the + length of the pathname. + + s_magic=0xNN + The ASCII base 16 representation of the + magic number of the filesystem that + contains the file. + + s_id=NAME + The ASCII name of the block device for + the filesystem that contains the file. + + s_UUID=HEX + The ASCII base 16 representation of + the hexadecimal value of the UUID of + the filesystem that contains the file. + + digest=HEX + The ASCII base 16 representation of + the SHA256 digest of the file. + + If the event type is the memory mapping of a file the + mmap_file{} event description will be included with + the following characteristics: + + type=N + Where N is an ASCII 0 or 1 to indicate + whether or not the mapping is file + backed or anonymous. A value of 1 is + used to indicate an anonymous mapping. + + reqprot=NN + Where N is ASCII base 10 + representation of the protections + requested for the mapping. + + prot=NN + Where N is the ASCII base 10 + representation of the protections that + will be applied to the mapping. + + flags=NN + Where N is the ASCII base 10 + representation of the flags that will + be used for the memory mapping operation. + + If the event type is a socket creation event the + socket_create{} event description will be included + with the following characteristics: + + family=N + Where N is the ASCII base 10 + representation of the family of the + socket that is being created. + + type=N + Where N is the ASCII base 10 + representation of the type of the + socket being created. + + protocol=N + Where N is the ASCII base 10 + representation of the socket protocol. + + kern=N + Where N is an ASCII 0 or 1 that is + used to represent whether or not this + is a kernel base socket. A value of 1 + indicates a kernel based socket. + + If the event type is a socket creation event the + socket_create{} event description will be included + with the following characteristics: + + If the event type is a socket_connect or a socket_bind, + a socket_connect{} or a socket_bind{} field will be + included that will be characterized based on an + encoding of either an IPV4, IPV6 or a generic socket + description. + + family=N + Where N is the ASCII base 10 + representation of the family type of + the socket. + + port=N + Where N is the base ASCII base 10 + representation of the port number that + is being used for either an IPV4 or + IPV6 socket connection or bind. + + addr=N | HEXID + In the case of an IPV4 socket the + value for the addr key will be the + ASCII base 10 representation of the 32 + bit IPV4 address being bound or + connected to. + + In case case of an IPV6 connection the + value to the key will be the ASCII + base 16 representation of the 128 bit + address being bound connected. + + In the case of any other type of + socket the addr value will be the + ASCII base 16 representation of the + SHA256 checksum over the entire length + of the address description. + + flow=N + For an IPV6 socket the value of the + flow key will be the ASCII base 10 + representation of the flow identifier + assigned to the socket. + + scope=N + For an IPV6 socket the value of the + scope key will be the ASCII base 10 + representation of the scope identifier + assigned to the socket. + + If the event type is a socket_accept a socket_accept{} + field will be included characterizes either an IPV4, + IPV6 or a generic socket description with the + following event descriptions: + + family=N + Where N is the ASCII base 10 + representation of the family type of + the socket. + + type=N + Where N is the ASCII base 10 + representation of the type of the + socket being created. + + port=N + Where N is the base ASCII base 10 + representation of the port number that + is being used for either an IPV4 or + IPV6 socket connection or bind. + + addr=N | HEXID + In the case of an IPV4 socket the + value for the addr key will be the + ASCII base 10 representation of the 32 + bit IPV4 address being bound or + connected to. + + In case case of an IPV6 connection the + value to the key will be the ASCII + base 16 representation of the 128 bit + address being bound connected. + + In the case of any other type of + socket the addr value will be the + ASCII base 16 representation of the + SHA256 checksum over the entire length + of the address description. + +What: /sys/fs/tsem/ExternalTMA +Date: November 2022 +Contact: Greg Wettstein <greg@enjellic.com> +Description: + The ExternalTMA directory is a container directory + that hold files that will be used to export the + security events, and their associated parameters, for + externally modeled security domains/namespaces. + + The files created in this directory will be named by + the base 10 ASCII representation of the id value + assigned to the modeling domain/namespace. See the + documentation for the /sys/fs/tsem/id file in this + documentation for more details on this value. + + This file will is a read-only file that can be polled + by a userspace trust orchestration implementation to + process security events that are to be modeled by + an external Trusted Modeling Agent. + + The type of the exported event is the first keyword of + the line that is output and have the following + values and arguments: + + aggregate HEXID: + Where HEXID is the ASCII base 16 + representation of the 256 bit hardware + platform aggregate value. + + export pid{NNN} COE{} CELL_DEFINITION + Where the NNN in the pid field is the ASCII + base 10 value of the id of the process that is + executing the security event that will be + modeled. + + The COE field has the same format as the field + emitted for a trajectory or forensics event. + + The CELL_DEFINITION are the same field + definitions that are emitted for a trajectory + or forensics event. + + log process{name} event{type} action{type} + The log event is emitted when an untrusted + task attempts to execute a security event. + + The name value of the COE field is the name of + the process (comm value) that is executing the + security event. + + The type value of the event field is the name + of the security event being executed as + defined in the tsem_names array in the + security/tsem/tsem.c file. + + The type value of the action field is the type + of action the LSM enforced in response to + encountering the untrusted process. This + value will be either LOG or EPERM to represent + whether or not the trust violation is being + logged or enforced. + +What: /sys/fs/tsem/control +Date: November 2022 +Contact: Greg Wettstein <greg@enjellic.com> +Description: + The control file is the only writable file in the + filesystem and is used by the trust orchestrators to + configure and control the behavior of the TSEM + implementation. + + The following keyword and arguments are recognized: + + internal: + The internal keyword causes an internally + modeled domain to be created for the calling + process. + + external: + The external keyword causes an externally + modeled domain to be created for the calling + process. + + enforce: + The enforce keyword causes the modeling + domain/namespace of the process to enter + enforcing mode. In this mode a value of + -EPERM will be returned for a security event + that does not map into the current set of + allowed state points for the security model + being implemented for the domain/namespace. + + seal: + The seal keyword causes the security model + being implemented for the model to be placed + in sealed state. In this state the current + set of security event points is considered to + be the only set of valid points for the + domain/model. Any subsequent events that map + to a point not in the current model will be + considered a violation of the model. + + trusted PID: + The trusted keyword is used by a trust + orchestrator to indicate that the process + identified by the PID argument should be + allowed to run in trusted status. + + untrusted PID: + The untrusted keyword is used by a trust + orchestrator to indicate that the process + identified by the PID argument should be + allowed to run but designated as an untrusted + process. + + state HEXID: + The state keyword is used to indicate that the + security state point identified by the ASCII + base 16 encoded value should be loaded into + the current security model as a valid security + event state. + + pseudonym HEXID + The pseudonym keyword is used to indicate that + the pathname, identified by the 256 bit ASCII + base 16 encoded value HEXID, should be + designated to return a constant digest value + for the contents of the file. + + The HEXID value is computed with the following + function: + + HEXID = SHA256(PATHNAME_LENGTH || PATHNAME) + + base HEXID + The base keyword is used to indicate that the + 256 bit ASCII base 16 encoded value HEXID + should be registered as the value used to + generate model specific security event points. + + A model specific base value is designed to be + used as a 'freshness' nonce, similar to an + attestation nonce, to prove that a model state + value or measurement is current and not being + replayed. diff --git a/Documentation/admin-guide/LSM/index.rst b/Documentation/admin-guide/LSM/index.rst index a6ba95fbaa9f..cebd3b02598d 100644 --- a/Documentation/admin-guide/LSM/index.rst +++ b/Documentation/admin-guide/LSM/index.rst @@ -47,3 +47,4 @@ subdirectories. tomoyo Yama SafeSetID + tsem diff --git a/Documentation/admin-guide/LSM/tsem.rst b/Documentation/admin-guide/LSM/tsem.rst new file mode 100644 index 000000000000..f03e5269cd25 --- /dev/null +++ b/Documentation/admin-guide/LSM/tsem.rst @@ -0,0 +1,1240 @@ +==== +TSEM +==== + + "This is the story of the wine of Brule, and it shows what + men love is never money itself but their own way, and + that human beings love sympathy and pageant above all + things." + - Hilaire Belloc + The Path to Rome + +TSEM is the Trusted Security Event Modeling system. Conceptually it +can be thought of as an integration of system integrity measurement +and mandatory access controls. + +The design and implementation of TSEM was inspired by the notion that +the security behavior of a platform, or a workload, like all other +physical phenomenon, can be mathematically modeled. + +Security, is at once, both a technical and economic problem. One of +the objectives of TSEM is to address inherent and structural economic +barriers to security, by introducing technology that reduces the skill +and time needed to implement a level of security, equivalent to what +can be achieved by mandatory access controls, through unit testing of +an application stack. + +A second objective, is to reduce the skill, complexity and +infrastructure needed to create remotely attestable platforms and/or +workloads. + +To achieve these objectives, TSEM implements the concept of a modeling +domain, nee namespace, that reduces the complexity of a security model +and allows it to be scoped to the level of a single process or a +container. + +TSEM is the Linux kernel component of a security concept introduced by +the Quixote Project, the notion of a Trust Orchestration System (TOS). +The concept of a TOS is to have a system with a minimal Trusted +Computing Base (TCB) that supervises and maintains subordinate +modeling domains/namespaces in a known trust state. + +TSEM is implemented as a Linux Security Module (LSM) and is designed +to be self-contained with little or no dependency on kernel +infrastructure, other than the LSM hooks themselves. It can be +stacked in any order with existing LSM's. Integrity modeling of +extended attributes would require that TSEM be earlier in the LSM call +chain then any LSM's that consume the modeled attributes. + +In addition, TSEM implements its equivalent of mandatory access +controls, without a requirement for extended attributes, filesystem +labeling or the need to protect filesystem metadata against offline +attack. + +TBDHTTRAD +========= + +A quick summary for those interested in experimenting with trust +orchestration and security modeling but are constrained by: 'Too Busy +Don't Have Time To Read Any Documentation'. + +A kernel with TSEM support in its list of enabled LSM's must be +available for use. A TSEM enabled kernel will have the tsem keyword +in the following file: + +/sys/kernel/security/lsm + +The trust orchestrators need to have access to the TSEM management +filesystem, that after boot, can be mounted with the following +command: + +mount -t tsemfs tsemfs /sys/fs/tsem + +For experimentation, or integrating TSEM modeling into a CI +development workflow, modeling can be restricted to subordinate +modeling domains by booting a kernel with the following kernel +command-line option: + +tsem_mode=1 + +The Quixote trust orchestration utilities either need to be built or +the statically compiled demonstration system needs to be installed. +Source for the userspace utilities and compiled sample programs are +available at the following location: + +ftp://ftp.enjellic.com/pub/Quixote + +After installing the utilities, two shell sessions will be needed with +root privileges in each shell. + +The following directories need to be in the PATH variable of each shell: + +/opt/Quixote/sbin +/opt/Quixote/bin + +Execute the following command to start a process in an independent +modeling domain/namespace with the security modeling being done in the +kernel: + +quixote -P -c test -o test.model + +In the second shell session, run the following command to display the +security execution trajectory of the model: + +quixote-console -p test -T + +In the shell session provided by the trust orchestrator, run the +following command: + +grep SOME_STRING /etc/passwd + +Then exit the shell. + +The orchestrator will indicate that the security model definition has +been written to the test.model file. + +Run the following command to execute a shell in an enforced security +model obtained from the previous session: + +quixote -P -c test -m test.model -e + +In the shell that is provided, run the following command: + +cat /etc/passwd + +The command will fail. + +Running the following command in the second shell session will output +forensics on the command that failed: + +quixote-console -p test -F + +Executing additional commands in the trust orchestrated shell will +cause additional entries to be added to the forensics trajectory. + +The test can be repeated using the quixote-us trust orchestrator. +This test will model the security domain/namespace in a userspace +process rather than in the kernel based modeling agent. + +Mandatory Access Controls +========================= + + "If I have seen further it is by standing on the shoulders of + Giants." + - Sir Isaac Newton + +It is assumed that astute readers will be familiar with classic +subject/object based mandatory access controls; or at least astute +enough to use a search engine to develop a modicum of secundem artem +in the discipline. + +Very simplistically, subject/object based mandatory access controls +can be thought of as being implemented with a two dimensional access +vector matrix, with some type of a description of a process (subject) +on one axis and a description of a data sync/source (object), +typically an inode, on the second axis. The descriptions are +commonly referred to as subjects and objects. + +A security policy is developed that assigns a boolean value for each +element of the matrix that specifies whether or not permission should +be granted for the subject to access the object. + +These schemes are frequently referred to as 'mandatory access +controls', since only the kernel has the ability to implement the +labeling and decision process. In these systems, the root or +administrative user has no ability to affect the kernel decision +making with respect to whether or not permission is granted or denied. + +These systems were derived from governmental and military information +classification systems and are capable of delivering security +guarantees appropriate to classified and high sensitivity assets. The +delivery of these security guarantees comes with it a reputation for +complexity and fragility. + +Development of a system wide security policy is a complex process and +administration of such systems is frequently done in an iterative +fashion. The system is monitored for permission denials with +modifications to correct these false denials folded back into the +policy. In many cases, mandatory access control systems are run in +warning rather than enforcing mode and used as an indicator for +potential security violations. + +One of the additional challenges is that the integrity of labels is +fundamental to the ability of these systems to deliver their security +guarantees. This requires that the labeling process be conducted +under security controlled conditions with the labels protected against +offline modification by cryptographic integrity guarantees. + +Mandatory access controls had their origin in centralized multi-user +platforms, and before the now, widely accepted strategy of using +resource compartmentalization (namespaces) to isolate applications +from each other and the system at large. A legitimate technical +argument can be made as to whether or not enforcement of a system wide +security policy is suitable for these environments. + +At the other end of the spectrum, in embedded systems, structural +economic barriers incent very little attention to security, where time +to market is the primary goal. These systems are pushed into the +field, many time for multi-year operational lifetimes, with little +prospect for upgrades or any notion of an iterative tuning process of +a security policy. + +Security Event Modeling +======================= + + "We can no longer speak of the behavior of the particle + independently of the process of observation. As a final + consequence, the natural laws formulated mathematically in + quantum theory no longer deal with the elementary particles + themselves but with our knowledge of them. Nor is it any + longer possible to ask whether or not these particles exist in + space and time objectively ... When we speak of the picture of + nature in the exact science of our age, we do not mean a + picture of nature so much as a picture of our relationships + with nature. ...Science no longer confronts nature as an + objective observer, but sees itself as an actor in this + interplay between man and nature. The scientific method of + analysing, explaining and classifying has become conscious of + its limitations, which arise out of the fact that by its + intervention science alters and refashions the object of + investigation. In other words, method and object can no longer + be separated." + - Werner Karl Heisenberg + +Security Event Modeling (SEM), is an alternative strategy to implement +the security guarantees of mandatory access and integrity controls, in +a manner that is consistent with emerging application development +strategies such as namespaces and continuous integration testing. + +As was noted at the start of this document, the premise for SEM is +that the security behavior of a platform, or alternatively a workload, +can be modeled like any other physical phenomenon in science and +engineering. + +Inspiration for this came from the primary TSEM author/architect +having trained as a quantum chemist, conducting very early research in +the development of multi-scale modeling strategies for molecules of +size to be of interest to pharmaceutical intents. + +SEM is premised on the theory that kernel security architects have +instrumented the LSM security event hooks to be called from all +locations, with appropriate descriptive parameters, that are relevant +to the security posture of the kernel. With respect to modeling, the +security event hooks are conceptualized as representing the +independent variables of a basis set that yields a functional +definition for the security state of an execution trajectory. + +SEM can be framed in the context of classic subject/object mandatory +access controls, by the notion that a unique identity can be generated +for each element of an access vector matrix, rather than a boolean +value. In SEM, a security execution trajectory is defined by the set +of points in an access vector matrix that a process hierarchy +(workload) references. This execution trajectory produces a vector of +identities, whose sum in an appropriate form, yields a functional +definition of the security state of the system. + +Two subordinate identities are combined to yield a security event +state point. These subordinate identities are referred to as the +Context Of Execution (COE) and the CELL, which are conceptually +similar to the subject and objects in mandatory access control. The +COE identity is derived from the parameters that describe the security +relevant characteristics of a process, while the CELL value is derived +from the parameters used by a security event hook to describe the +characteristics of the event. + +A security policy is implemented by a modeling algorithm that +translates COE and CELL event parameters into their respective +identities. Different security policies can be developed by modifying +how the modeling algorithm utilizes the COE and CELL characteristics. + +Since the security policy is implemented with a modeling algorithm, a +single platform can support multiple and arbitrary security policies. +The equivalent of a resource namespace in SEM is referred to as a +modeling domain and can be conceptualized as a mandatory access +control or integrity namespace. + +The formation of the security event state points from existing kernel +parameters eliminates the need for the use of extended attributes to +hold security label definitions. In SEM, a cryptographically signed +security model definition, designed to be interpreted by a modeling +engine, becomes the bearer's token for the security of the modeling +target, rather than information encoded in filesystem security +attributes. + +Trusted Security Event Modeling +=============================== + + "Do you see over yonder, friend Sancho, thirty or forty + hulking giants? I intend to do battle with them and slay + them." + - Don Quixote + +In TSEM, the modeling algorithm is implemented in an entity known as a +Trusted Modeling Agent (TMA), in a 'trusted' environment where +modeling is immune from modification or alteration by any activity on +the platform or in a workload. The notion of a TMA provides a +framework for next generation security co-processors that extend +beyond what is defined by the concept of a Trusted Platform Module +(TPM). + +In addition to providing an attestation of an execution trajectory, a +TMA, in contrast to a TPM, has the ability to advise an operating +system on whether or not an event being modeled is consistent with the +security policy that is being enforced. In this manner, it introduces +a prospective rather than a retrospective trust model. + +TSEM is designed to support Trust Orchestration Systems (TOS). In a +TOS, the trust orchestrators are supervisory programs that run +workloads in independent modeling domains, enforcing a workload +specific security model. Each trust orchestrator is paired with a +'trusted partner TMA', that implements the workload specific modeling +algorithm. + +The root of trust for a workload modeling domain is based on where the +TMA instance is implemented. As an example, the Quixote TOS +implementation currently offers orchestrators for the following TMA +execution localities: + +- Kernel. + +- Userspace process. + +- SGX enclave. + +- Xen stub domain. + +- Micro-controller. + +This partitioning of trust results in the concept of security domains +being referred to as internally or externally modeled. A TMA +implementation run in the kernel is referred to as an internally +modeled domain; TMA's run outside of the kernel are referred to as +externally modeled domains. + +The TMA, regardless of locality, is responsible for processing the +characteristics that describe a security event, computing the identity +for the COE and CELL and then combining these two identities to create +a security event state point. With respect to modeling theory, the +security event state point is a task specific coefficient representing +the event in a security model. + +TSEM is dispassionate with respect to the type of algorithm that is +implemented. The processing of the security event characteristics and +their conversion to state points, is driven by the security +model/policy that will be implemented for the workload. It is +assumed, that security model algorithms will embrace various +approximations, and perhaps even stochastic reasoning and machine +learning methods, as new security models are developed in response to +specific workload, platform and device requirements. + +A security model, to be enforced by a trust orchestrator, is +implemented by providing the TMA with a set of security state points +that are to be observed. A TMA processes the characteristics of a +security event and converts the characteristics to a state point that +is evaluated against the state points provided to the TMA as the +reference security behavior of a workload. + +A security event that translates to one of the provided 'good' points, +will cause the TMA to indicate to the trust orchestrator that the +process is to be allowed to run as a trusted process. A security +event that does not map to a known good point, results in the trust +orchestrator designating that the process be run as an untrusted +process. + +Trust orchestrators and their associated TMA's, are designed to +support signed security models. This results in the elimination of +the requirement to verify or appraise extended attributes and other +measures currently required to protect trusted security systems +against offline attacks. + +The use of a cryptographic hash function to generate the security +state points results in the definition of very specific security +behaviors, that are sensitive to any variation in their +characteristics. Any offline modifications to files will result in a +security state point that is inconsistent with a signed model provided +to a TMA. + +In order to support the development of TSEM based security models, a +TMA is designed to run in one of three separate modes, referred to as +follows: + +- Free modeling. + +- Sealed. + +- Enforcing. + +In a free modeling configuration, the TMA adds the security state +point for the characteristics of a security event to the current set +of known good states. In addition, the description of the security +event is retained as a member of the security execution trajectory for +the model. This mode is used, in combination with unit testing of a +workload, to generate a security model for subsequent enforcement. + +Placing a TMA in 'sealed' mode implies that any subsequent security +events, that do not map into a known security state point, are to be +considered 'forensic' violations to the security state of the model. +A forensics mapping event does not cause the initiating process to be +placed in untrusted mode; it is designed to provide the ability to +either fine tune a model or provide early warning of a potential +attempt to subvert the security status of a workload. + +Placing a TMA model in 'enforcing' status implies that the model is in +a sealed state and any subsequent violations to the model will result +in a violating process being placed in untrusted status. The +characteristics of the violating event will be registered in the +forensics trajectory for the model for use in subsequent evaluation of +the violating event and/or model refinement. + +Process and Platform Trust Status +================================= + +A fundamental concept in TSEM is the notion of providing a precise +definition for what it means for a platform or workload to be trusted. +A trusted platform or workload is one where there has not been an +attempt by a process to execute a security relevant event that does +not map into a known security state point. + +The process trust status is a characteristic of the process that is +passed to any subordinate processes that are descendants of that +process. Once a process is tagged as untrusted, that characteristic +cannot be removed from the process. In a 'fruit from the poisoned +vine' paradigm, all subordinate processes created by an untrusted +process are untrusted as well. + +On entry into each TSEM security event handler, the trust status of a +process is checked before an attempt to model the event is made. An +attempt to execute a security event by an untrusted process will cause +the event, and its characteristics, to be logged. The return status +of the hook will be determined by the enforcement state of the model. +A permission denial is only returned if the TMA is running in +enforcing mode. + +If the platform running the TSEM LSM has a TPM, the hardware aggregate +value is computed at the time that TSEM is initialized. This hardware +aggregate value is the linear extension sum over Platform +Configuration Registers (PCR's) 0 through 7. This is the same +aggregate value that is computed by the Integrity Measurement +Architecture (IMA) and is the industry standard method of providing an +evaluation measurement of the hardware platform state. + +Internally model domains have the hardware aggregate measurement +included as the first state point in the security model. Externally +modeled domains export the hardware aggregate value to the TMA for +inclusion as the first state point of the model maintained by the TMA. + +The root modeling domain extends each security state point into PCR +11. This allows hardware based TSEM measurements to coexist with IMA +measurement values. This hardware measurement value can be used to +attest to the security execution trajectory that the root model +maintains. + +TSEM operates under the assumption that the root domain will be a +minimum Trusted Computing Base implementation that will only be +running trust orchestrators. Subordinate modeling domains are +designed, deliberately, to be non-hierarchical, so as to decrease +model complexity in the subordinate domains in order to support a +single functional value describing the security state of a security +domain. + +The Linux TSEM Implementation +============================= + + "Sometimes the questions are complicated and the answers are + simple." + - Dr. Seuss + +The Linux TSEM implementation is deliberately simplistic and consists +of the following two generic components: + +- Modeling namespace and security event export functionality. + +- Internal trusted modeling agent. + +The modeling namespace and export functionality is designed to be +generic infrastructure that allows security domains to be created that +are either internally or externally modeled. The TSEM implementation +does not pose any constraints on what type of modeling can or should +be implemented in these domains. + +On the theory that security event handlers represent all of the +security relevant points in the kernel, any security or integrity +model can be implemented using the TSEM infrastructure. For example, +basic IMA functionality could be implemented by a TMA that maps the +digests of files accessed, or mapped executable, by the root user as +the security state points. + +A primary intent of the Linux TSEM implementation is to provide a +generic method for implementing security policy in userspace rather +than the kernel. This is consistent with what has been the historic +understanding in Linux architecture, that policy decisions should be +delegated, when possible, to userspace rather than to kernel based +implementations. + +The model is extremely simplistic; a TMA interprets a security event +and its characteristics and advises whether or not the kernel should +designate the process as trusted or untrusted after event processing +is complete. + +The following sections discuss various aspects of the infrastructure +used to implement this architecture. + +Internal vs external modeling +----------------------------- + +When a TSEM modeling domain is created, a designation is made as to +whether the domain is to be internally or externally modeled. + +In an internally modeled domain, the security event handlers pass the +event type and its characteristics to the designated internal trusted +modeling agent. The agent provides the permission value for the +security event handler to return as the result of the event and sets +the trust status of the process executing the event. + +In an externally modeled domain, the event type and parameters are +exported to userspace for processing by a trust orchestrator with an +associated TMA. The trust orchestrator communicates the result of the +modeling back to the kernel to support the setting of the process +trust status. + +This model poses a limitation to the ability of TSEM to model some +security events. This is secondary to the fact that some event +handlers (LSM hooks) are called from a non-sleeping context, as a +result the process cannot be scheduled. This is particularly the case +with the task based hooks, since they are typically called with the +tasklist lock held. + +This limitation is also inherent to the root model that extends the +security state points into TPM PCR 11, secondary to the fact that the +process invoking the security event hook will be scheduled away while +the TPM transaction completes. + +Addressing this problem directly requires a consideration of the +context from which the security event handlers are being called. +Subsequent implementations of TSEM will include a mechanism for +asynchronous deferral of model processing, until when and if, a review +of the call context would be considered worthwhile by the LSM +community. + +Event handlers that cannot be directly modeled, still consider, on +entry, whether or not they are being called by an trusted or untrusted +process. As a result, an untrusted process will cause a non-modeled +event to return a permissions violation in enforcing mode, even if the +security event cannot be directly modeled. + +Security event modeling typically traps violations of trust by a COE +with unmodeled characteristics that is attempting to access/execute a +file or map memory as executable; or by a COE with known +characteristics attempting to access or execute a CELL not prescribed +by a model. As a result, the impact of the ability to not directly +model these events is lessened. + +Explicit vs generic modeling +---------------------------- + +In addition to the COE characteristics, TMA's have the ability to +include the parameters that characterize the CELL of the security +event into the generation of the security state point for the event. +The inclusion of the CELL characteristics is considered explicit +modeling of the event. + +TMA's also have the ability to consider only the COE characteristics +and the type of the event. This is referred to as generic modeling of +the event. + +In the current Linux TSEM implementation, the security event handlers +differentiate, primarily due to code maturity reasons, some events to +be generically modeled. For these events, in addition to the COE +characteristics and task identity, a default CELL value is used in the +computation of the security state point. + +As was noted in the section on 'internal vs external modeling', the +most common violation of trust is the initial execution of a binary or +access to a file. The inclusion of events, as generically modeled, +allows the capture of security behaviors that are inconsistent with a +proscribed security model, even if full characterization of the event +is not implemented. + +In the following ABI document: + +Documentation/ABI/testing/tsemfs + +The /sys/fs/tsem/trajectory entry documents parameters that are +available for modeling by both internally and externally modeled +domains. + +Event modeling +-------------- + +TSEM security event modeling is based on the following functional +definition for a security state point: + +Sp = SHA256(SHA256(EVENT_ID) || TASK_ID || SHA256(COE) || SHA256(CELL)) + + Where: + || = Concatenation operator. + + EVENT_ID = ASCII name of event. + + TASK_ID = 256 bit identity of the process executing + the security event. + + COE = Characteristics of the context of execution + of the event. + + CELL = Characteristics of the object that the + security event is acting on. + +Workload or platform specific security point state definitions are +implemented by a TMA using whatever COE or CELL characteristics that +are considered relevant in determining whether or not a process should +be considered trusted or untrusted. + +The TASK_ID component of the function above is important with respect +to the generation of the security state points. The notion of a task +identity serves to link the concepts of system integrity and mandatory +access control. + +The TASK_ID is defined by the following function: + +TASK_ID = SHA256(SHA256(EVENT) || NULL_ID || SHA256(COE) || SHA256(CELL)) + + Where: + || = Concatenation operator. + + EVENT = The string "bprm_set_creds". + + NULL_ID = A buffer contain 32 null bytes (0x00). + + COE = Characteristics of the context of execution + calling the bprm_creds_for_exec LSM hook. + + CELL = The characteristics of the file provided + by the linux_binprm structure passed to + the security hook. + +An informed reader will quickly conclude, correctly, that the TASK_ID +function generates an executable specific security state point for the +bprm_creds_for_exec security hook. The function is the same as the +standard security point; with the exception that the task identity is +replaced with a 'null id', one that consists of 32 null bytes. + +One of the CELL characteristics used in the computation of the task +identity is the digest of the executable file. Modifying an +executable, or attempting to execute a binary not considered in the +security model, will result in an alteration of the task identity that +propagates to the generation of invalid state points. + +The task identity is saved in the TSEM specific task structure and is +used to compute the state points for any security events that the task +subsequently executes. As noted in the previous paragraph, +incorporating the TASK_ID into the computation of security state +points results in the points becoming executable specific. This +affords a very degree of specificity with respect to the security +models that can be implemented. + +As was demonstrated in the TBDHTTRAD section, TSEM will discriminate +the following commands as different events/coefficients in a security +model: + +cat /etc/shadow + +grep something /etc/shadow + +while read input +do + echo $input; +done < /etc/shadow + +An important, and perhaps subtle issue to note, is how these events +result in the change of process trust status. In the first two cases, +if access to the /etc/shadow file is not permitted by the operative +security model, the cat and grep process will become untrusted. + +In the third example, the shell process itself would become untrusted. +This would cause any subsequent attempts to execute a binary to be +considered untrusted events, even if access to the binary is a +permitted point in the model. + +Since the modeling operates at the level of mandatory access controls, +these permission denials would occur even if the process is running +with root privilege levels. This is secondary to the notion that +security and trust status are invested in the trust orchestrator and +ultimately the TMA. + +From a hardware perspective, this is important with respect to the +notion of a TMA being a model for a successor to the TPM. From a +system trust or integrity perspective, a TPM is designed to provide a +retrospective assessment of the actions that have occurred on a +platform. A verifying party uses the TPM event log and a PCR based +summary measurement, to verify what actions have occurred on the host, +in order to allow a determination of whether or not the platform +should be 'trusted'. + +In contrast, a TSEM/TMA based system enforces, on a real time basis, +that a platform or workload remains in a trusted state. Security +relevant actions cannot be conducted unless the TMA authorizes the +actions as being trusted. + +This is particularly important with respect to embedded systems. A +TPM based architecture would not prevent a system from having its +trust status altered. Maintaining the system in a trusted state would +require attestation polling of the system, and presumably, executing +actions if the platform has engaged in untrusted behavior. + +Conversely, a trust orchestrated software implementation enforces that +a system or workload remain in a security/trust state that it's +security model was unit tested to. + +Security model functional definitions +------------------------------------- + +Previously, classic trusted system implementations supported the +notion of the 'measurement' of the system. The measurement is the +value of a linear extension function of all the security relevant +actions recorded by a trust measurement system such as IMA. + +In TPM based trust architectures, this measurement is maintained in a +PCR. A measurement value is submitted to the TPM that extends the +current measurement using the following formula: + +MEASUREMENT = HASH(CURRENT || NEW) + + Where: + || = Concatenation operator. + + MEASUREMENT = The new measurement value to be maintained + in the register for the system. + + CURRENT = The current measurement value. + + NEW = A new measurement value to be added to + the current measurement. + + HASH = A cryptographic hash function. + +In TPM1 based systems the HASH function was SHA1. Due to well +understood security concerns about the cryptographic vitality of this +function, TPM2 based systems provide additional HASH functions with +stronger integrity guarantees, most principally SHA related functions +with longer digest values such as SHA256, SHA384 and SM3. + +The use of a cryptographic function produces a non-commutative sum +that can be used to verify the integrity of a series of measurements. +With respect to security modeling theory, this can be thought of as a +'time-dependent' measurement of the system. Stated more simply, the +measurement value is sensitive to the order in which the measurements +were made. + +In systems such as IMA, the measurement value reflects the sum of +digest values of what are considered to be security critical entities, +most principally, files that are accessed based on various policies. + +In TSEM based TMA's, the measurement of a modeling domain is the sum +of the security state points generated by the operative security model +being enforced. As previously noted, on systems with a TPM, the root +modeling domain measurement is maintained in PCR 11. + +The challenge associated with classic integrity measurements is the +time dependent nature of using a non-commutative summing function. +The almost universal embrace of SMP based hardware architectures and +standard kernel task scheduling makes the measurement values +non-deterministic. This requires a verifying party to evaluate an +event log, verified by a measurement value, to determine whether or +not it is security appropriate. + +TSEM addresses this issue by implementing a strategy designed to +produce a single functional value that represents the security state +of a model. This allows a TMA to attest to the trust/security status +of a platform or workload by signing this singular value and +presenting it to a verifying party. + +In TSEM nomenclature, this singular value is referred to as the +'state' of the model. The attestation model is to use trust +orchestrators to generate the state value of a workload by unit +testing. This state value can be packaged with a utility or container +to represent a summary trust characteristic that can be attested by a +TMA, eliminating the need for a verifying partner to review and verify +an event log. + +TMA's implement this architecture by maintaining a single instance +vector of all the set of security model state points that have been +generated. A state measurement is generated by sorting the vector in +big-endian hash format and then generating a standard measurement +digest over this new vector. + +Any security event that generates an associated state point that is +not in the model will resulted in a perturbed state function value. +That perturbed value would be interpreted by a verifying party as an +indication of an untrusted system. + +Since the TMA maintains the security event descriptions in time +ordered form the option to provide a classic event log and measurement +are preserved and available. Extensive experience in the development +of TSEM modeled systems has demonstrated the superiority of state +value interpretation over classic measurement schemes. + +A TMA may choose to incorporate a 'base nonce' into a security model +that is is implementing, this based nonce is designed to serve in a +manner similar to an attestation nonce. If used, the trust +orchestrator is responsible for negotiating a random base nonce with a +verifying party at the time of initialization of a modeling namespace +and providing it to the TMA. + +The TMA uses the base nonce to extend each security event state point +that is generated by the model. This causes the state and measurement +values of the model to become dependent on this base nonce, a process +that can be used to defeat a replay attack against the security model. + +Control plane +------------- + +Both primary functions of TSEM: security modeling domain management +and the internal TMA implementation, are controlled by the tsemfs +pseudo-filesystem, that uses the following mount point: + +/sys/fs/tsem + +The following file documents, in detail, the interfaces provided by +the filesystem: + +Documentation/ABI/testing/tsemfs + +This filesystem is primarily intended for use by trust orchestrators +and must be mounted in order for orchestrators to create and manage +security modeling domains. + +The following files grouped below by generic functionality, are +presented in the filesystem: + + control + + id + aggregate + + measurement + state + points + trajectory + forensics + +The /sys/fs/tsem directory contains the following sub-directory: + + ExternalTMA + +That is used to hold files that will be used to export security event +descriptions for externally modeled domains. + +The files are process context sensitive. Writing to the control file +or reading from the informational files, will act on or reference the +security domain that the access process is assigned to. + +The TSEM implementation at large is controlled by the only writable +file, which is the 'control' file. + +The following keywords are used by trust orchestrators to create +internally or externally modeled security domains for the writing +process: + + internal + external + +The following keywords are used by trust orchestrators to set the +trust status of a process after processing of a security event by an +external TMA: + + trusted PID + untrusted PID + + Where PID is the process identifier that is provided to the + TMA in the security event description + +By default a modeling domain runs in free modeling mode. The modeling +mode is changed by writing the following keywords to the control file: + + seal + enforce + +The following keyword and argument are used to load a security model +into an internal modeling domain: + + state HEXID + + Where HEXID is the ASCII base 16 representation of a security + state point that is represents a valid security event in the + model. + + After writing a series of state values the trust orchestrator + would write the 'seal' keyword to the control file to complete + creation of a security model. Writing the 'enforce' keyword + to the control file will result in that model being enforced. + +The following keyword and argument is used to set a base nonce for the +internal TMA: + + base HEXID + + Where HEXID is the ASCII base 16 representation of a value + that each measurement is to be extended with before being + committed as a measurement value for the model. + +The following keyword and argument is used to create a file digest +pseudonym for the internal TMA: + + pseudonym HEXID + + Where HEXID is the ASCII base 16 representation of a file + digest pseudonym that is to be maintained by the model. See + the ABI documentation for how the argument to this verb is + generated. + +The 'id' file is used to determine the modeling domain that the +process is running in. The domain id value of 0 is reserved for the +root modeling domain, a non-zero value indicates that the process is +running in a subordinate modeling domain. + +The 'aggregate' file is used by trust orchestrators for internally +modeled domains to obtain the hardware measurement value. A trust +orchestrator for an internally modeled domain needs this value in +order to generate a platform specific security model for subsequent +enforcement. A trust orchestrator for an externally modeled domain +can capture this value since it is exported, through the trust +orchestrator, to the TMA. + +The remaining five files: measurement, state, points, trajectory and +forensics, are used to export the security model characteristics of +internally modeled domains. + +The 'measurement' file outputs the classic measurement value of the +modeling domain that the calling process is running in. This value is +the linear extension sum of the security state points in the model. + +The 'state' file outputs the security state measurement value as +described in the 'Security model functional definitions' section of +this document. + +The 'points' file outputs the set of security state points in the +model. These points represent both valid and invalid state points +generated by the security model implemented for the domain. + +The 'trajectory' file outputs the description of each security event +recorded by the model in time dependent form. + +The 'forensics' file outputs the description of security events that +have occurred when the domain security model is running in a sealed +state. + +The ABI documentation file contains a complete description of the +output that is generated by each of these files. + +A security model for an internally modeled domain is loaded by +writing the valid security points to the 'state' file in the control +plane. This will result in the 'trajectory' file having no event +descriptions for a sealed model, since the event description vector is +only populated when a new state point is added to the model. + +Since the state points are generated with a cryptographic hash +function, the first pre-image resistance characteristics of the +function prevents a security model description from disclosing +information about the characteristics of the workload. + +Trust orchestrators +=================== + +In security modeling, the need for a trust orchestrator system is +embodied in Heisenberg's reflections on quantum mechanical modeling. +A modeled system cannot model itself without affecting the functional +value of the security model being implemented. An external entity is +needed to setup, configure and monitor the state of a modeled system, +in a manner that does affect the state of the modeled system itself. + +After creating and configuring a modeling domain, the orchestrator is +responsible for executing and monitoring a process that is run in the +context of the domain. The trust orchestrator is also responsible for +providing access to the security model implemented by the TMA. + +Trust orchestrators for externally modeled domains, have an +associated TMA that is responsible for implementing the security model +for a domain. The TMA represents the the root of trust for the +modeled domain. The TMA advises the trust orchestrator as to what the +new trust status for a process should be set to, based on the modeling +of the security event that is presented to it by the trust +orchestrator. + +In a trust orchestration architecture, secondary to their integral +role in maintaining the trust state of the system, the trust +orchestrators are the highest value security asset running on the +system. In order to support this the Linux TSEM implementation +implements a new security capability, CAP_TRUST, that only the trust +orchestrators are designed to run with. + +The CAP_TRUST capability is defined as a capability that allows the +ability of it's holder to modify the trust state of the system. The +ability to create the proposed IMA namespaces would also be a +candidate for this capability. + +Trust orchestrators are designed to drop the CAP_TRUST capability +before forking the process that will be responsible for launching a +modeled workload. This provides an architecture where the root of +trust for the system can be predicated on a small body of well audited +orchestration utilities, that can be linked to a hardware root of +trust implemented by a TPM or hardware based TMA. + +Quixote +======= + + "He is awkward, past his prime and engaged in a task beyond his + capacities." + - Don Quixote's able mount Rocinante + +The Quixote Trust Orchestration System, released in concert with TSEM, +is an initial implementation of a system that embodies the +characteristics described above. While currently under development by +a small team, it provides all off the basic functionality needed to +demonstrate, and use, TSEM based security modeling. + +It is anticipated that Quixote would not be the only such system to +take advantage of TSEM. Given the burgeoning capability set of +systemd, it would be an architecturally valid concept to have systemd, +or other system init equivalents, gain the ability to launch critical +system services in modeled environments. + +The source code for Quixote, and patches to the LTS kernels back to +5.4, are available at the following URL: + +ftp://ftp.enjellic.com/pub/Quixote + +The build of Quixote is somewhat formidable, given that it spans the +range from system programming though SGX programming and into embedded +micro-controller systems. In order to facilitate experimentation, +binaries pre-compiled against MUSL libc are provided that have +virtually no system dependencies, other than a TSEM enabled kernel. + +Sample utilities +---------------- + +The Quixote TSEM implementation implements a separate trust +orchestration utility for each TMA environment, nee Sancho partner, +that is supported: + +quixote -> TMA run in the kernel for internally modeled domains. + +quixote-us -> TMA run in a userspace process. + +quixote-xen -> TMA run in a Xen based stub domain. + +quixote-sgx -> TMA run in an SGX enclave. + +quixote-mcu* -> TMA run in a micro-controller implementation. + +* = See discussion below. + +Each utility runs in one of two modes: process or container + +In process mode, a shell process is run as the workload process in +modeling domain. This mode is selected with the -P command-line +option. + +In container mode, the default, the OCI runc utility is run as the +workload process, with a 'bundle' argument that specifies a directory +that contains a JSON container definition for a directory hierarchy in +the bundle directory. The /var/lib/Quixote/Magazine directory +contains the bundle directories. + +The -c command-line option selects container mode, the argument to the +option specifies the bundle directory for the runc utility. + +In order to support the creation of security models, each utility +supports the -o command-line option to specify that a security model +description be output when the modeled workload terminates. The model +is written name of the file supplied via the command-line option. + +If the -t command-line option is also specified, the security +execution trajectory, rather than a model definition, is written to +the output file. This trajectory represents the description of the +security events that were modeled. This trajectory can be converted +to security state points with the generate-states utility that is also +provided in the utilities package. + +The -m command-line option is used to specify a model that is to be +loaded into the TMA and optionally enforced. By default the security +model output with the -o command-line option will place the TMA in a +sealed modeling state. Any security events that are non-compliant +with the model will be registered as forensics events. + +Adding the -e command-line option, with the -m option, will cause the +loaded model to be enforced. Any forensic events will cause a +permission denial to be returned to the caller of the LSM hook. + +The Quixote package also includes a utility, quixote-console, for +interrogating the model state of a TMA. The following command-line +options request output of the following characteristics of the model: + +-E -> The log of denied events. + +-F -> The current forensics execution trajectory. + +-M -> The current security model description. + +-P -> The current security state points. + +-S -> The state value of the model. + +-T -> The current security execution trajectory. + +Executing the utility, without these arguments, will cause a +command-line version of the utility to be presented that takes the +following arguments: + +show trajectory + +show forensics + +show points + +show state + +show model + +quit + +It is important to note that any of the values output represent the +current state of the model and do not reflect a cumulative model of +the workload. Capturing a complete workload model requires the use of +the -m command-line argument to the trust orchestrators to capture a +model that is representative of the entire execution trajectory of the +workload. + +For informative purposes the following security model definition +represents the execution and simple termination of a shell session run +on a system with a hardware TPM: + +aggregate de2b9c37eb1ceefa4bcbc6d8412920693d3272f30eb5ba98d51d2f898d620289 +state 97b29769580b412fbf55e326a98d6a1b97c6ebf446aaf78ea38c884e954ca5b2 +state 7c435854b4fa421175ec0a5d3ca7c156480913d85c03155ea3305afa56c9717d +state 554d9f62693d522c9a43acf40780065f99cea3d67ca629ac4eaab4e22d4e63c2 +state 1b228046c4c2e7aa14db9a29fcff6f718f4f852afbfb76c8a45af7bf0485f9ce +state 24fd04b10e2b5016e0061952f3bdea959e0fa80a55ff0f4e8e13f9f72ede7498 +state da6038511db71b08c49a838d178ed055e0b7bfc42548b4c2d71eca046e9a222e +state 94b24ad4c8902f8ecb578a702408e8458e72c0774c402c3bd09ec5f390c4d0ae +state 5ffa5a2a38f42d89ae74a6d58be8b687c1baed9746d9c6a7ae3c632a2e7c082f +state a2e309d84bd4a52466c22779a622254c65ad1208583d70113751c4624baa7804 +state e93ceb0b1bf3cd58373a9e9ab4aca11a507782bbfde395ff68f8bfaf1678ed43 +state bf42388d63887368605fac9816134bc67314762c3a97b440cc48c5a30c07fdb9 +state eaa342599d682d63be4b64e159b98f21d85f0133ef5b28588e444ad12e446bf6 +state 2b9c86bc34202504c398c2f177d1dcf807b2f267c160bf8ebda863a9b427917f +state 686fc3c958f2e4f2ce3b2c6a2cb3fff44ccc4db98869bd377b14e557a5191231 +state 613c39fd2a58413b32f448c13ea4d6bc38b77966dfc5560e39e4b37d2b2f5675 +state 70e276bfd7c20262cd9c9f5b09a922f11d16d1e3a602e8005d68e9ed6afc9b5d +state 456aaedc5c1fc63f852ee97ae9561aba2a06c416154ecb9d7a1bf9d9a8c9c064 +state 97507c4c91af4a9b34b4d66118f6cc0ba1f8b55b8bb6e623dcafe27b100aea07 +state ea635c48031f81140b3561ed2291a3b1790a302e6adf5244320593b08a5af924 +state 2fd6a4d6ea1869a193926e998fbdf855916b510257d379762f48a1df63a810d4 +state 9c4cb7ef4848be1e29f9eb35fadaf5bfdc1fa3cbb22b6407cbd31b7088257026 +state 66640cbf9ae772515070f8613182b6852bf46220df0833fbe6b330a418fad95b +state 6b0d1890cbd78c627e23d7a564e77a5ee88fb20e0662ce5e66f3727ebf75fa1d +state bd28fa43b34850591fdf6fb2aa5542f33c21c20ee91b4bc2034e199b4e09edc1 +state 04425354419e53e6e73cde7d61856ff27763c2be01934e9990c1ae9f8d2a0b6e +state 2650d86382f6404367b7fdeec07f873b67b9ce26caef09d035b4dff09fce04d5 +state df2f91f5fd84ca4621092420eaf1b0a3743b328a95e3f9e0b7b1281468462aa2 +state c730c66ecfabe99480e61a7f25962582ca7bb6f2b17983048e77adde1fe7f72b +state 0fc937b71d0067fcc2c2f37c060763de250b3142e621174ffedc1b2520cdf6fd +state 7f267400a3ccf462c77ae5129799558c2c62d8bc5b388882caec813ab4cf7b7f +seal +end + +As was previously discussed, the model should be cryptographically +secure against the elucidation of the security events that resulted in +the described security states. + +The Quixote package also contains utilities for generating signed +versions of these security models. In what is a nod to the politics +of trusted systems, the Quixote TMA implementations support +self-signed security models. + +* MCU TMA's +----------- + +One of the objectives of TSEM/Quixote is to explore architectures for +trusted systems that extend beyond what is provided by the TPM model +for security co-processors. The MCU based reference implementations +allow experimentation with hardware based TMA's. + +The Quixote TSEM utilities include TMA implementations for the +following following ARM32 based micro-controller platforms: + +STM32L496 + +STM32L562 + +NRF52840-DK + +NRF52840-DONGLE + +The STM32L496 platform, in addition to the base TMA implementation, +includes support for a CAT1-M based cellular modem. This demonstrates +the ability of an external TMA to conduct remote, out-of-band, +signaling of security violations for modeled platforms/workloads. + +The STM32L562 platform is a low power MCU designed for security +focused IOT implementations. It includes hardware hashing, hardware +asymmetric encryption and Trust Zone support. + +Of primary interest is the NRF52840-DONGLE implementation. This is a +'USB fob' form factor board that GOOGLE uses as the basis for its +OpenSK security key implementation. This form factor allows the +development and experimentation with deployable hardware based TMA +implementations. + +The NRF52840-DONGLE architecture was also chosen by the NLnet +sponsored 'FobNail' project, that is developing a hardware based +attestation server: + +https://fobnail.3mdeb.com/ + +The Fobnail projects discusses the notion of their architecture +expanding to provide protection for a Linux system at large. +Quixote/TSEM running, on the NRF52840-DONGLE micro-controller, is a +demonstration of such an implementation. + +=============== +Closing Remarks +=============== + + "Sometimes it is the people no one can imagine anything of who + do the things no one can imagine. + - Alan Turing + +While this document is of some length and detail, it hopefully +fulfills its obligation to provide sufficient prose for the +justification of the security model that TSEM addresses, and in +combination with trust orchestrators, implements. + +The MAINTAINERS file has contact information for feedback, patches +and/or questions regarding TSEM and its reference TOS implementation. + + The Quixote Team - Flailing at the Travails of Cybersecurity + + With all due respect to Miguel de Cervantes Saavedra. + + From the glacial moraine lake country of West-Central Minnesota. diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index 6cfa6e3996cf..a7dafcd932b4 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -6376,6 +6376,11 @@ with CPUID.16h support and partial CPUID.15h support. Format: <unsigned int> + tsem_mode= [TSEM] Set the mode that the Trusted Security Event + Modeling LSM is to run in. + Format: 1 + 1 -- Disable root domain modeling. + tsx= [X86] Control Transactional Synchronization Extensions (TSX) feature in Intel processors that support TSX control.
An entry was added to the ABI testing documentation to document the files in the TSEM management filesystem. The file documenting the kernel command-line parameters was updated to document the tsem_mode command-line parameter. The primary TSEM documentation file was added to the LSM administration guide and the file was linked to the index of LSM documentation. Signed-off-by: Greg Wettstein <greg@enjellic.com> --- Documentation/ABI/testing/tsemfs | 576 ++++++++ Documentation/admin-guide/LSM/index.rst | 1 + Documentation/admin-guide/LSM/tsem.rst | 1240 +++++++++++++++++ .../admin-guide/kernel-parameters.txt | 5 + 4 files changed, 1822 insertions(+) create mode 100644 Documentation/ABI/testing/tsemfs create mode 100644 Documentation/admin-guide/LSM/tsem.rst