mirror of https://github.com/torvalds/linux.git
ipe: Update documentation for script enforcement
This patch adds explanation of script enforcement mechanism in admin guide documentation. Describes how IPE supports integrity enforcement for indirectly executed scripts through the AT_EXECVE_CHECK flag, and how this differs from kernel enforcement for compiled executables. Signed-off-by: Yanzhu Huang <yanzhuhuang@linux.microsoft.com> Signed-off-by: Fan Wu <wufan@kernel.org>
This commit is contained in:
parent
67678189e4
commit
d7ba853c0e
|
|
@ -95,7 +95,20 @@ languages when these scripts are invoked by passing these program files
|
||||||
to the interpreter. This is because the way interpreters execute these
|
to the interpreter. This is because the way interpreters execute these
|
||||||
files; the scripts themselves are not evaluated as executable code
|
files; the scripts themselves are not evaluated as executable code
|
||||||
through one of IPE's hooks, but they are merely text files that are read
|
through one of IPE's hooks, but they are merely text files that are read
|
||||||
(as opposed to compiled executables) [#interpreters]_.
|
(as opposed to compiled executables). However, with the introduction of the
|
||||||
|
``AT_EXECVE_CHECK`` flag (:doc:`AT_EXECVE_CHECK </userspace-api/check_exec>`),
|
||||||
|
interpreters can use it to signal the kernel that a script file will be executed,
|
||||||
|
and request the kernel to perform LSM security checks on it.
|
||||||
|
|
||||||
|
IPE's EXECUTE operation enforcement differs between compiled executables and
|
||||||
|
interpreted scripts: For compiled executables, enforcement is triggered
|
||||||
|
automatically by the kernel during ``execve()``, ``execveat()``, ``mmap()``
|
||||||
|
and ``mprotect()`` syscalls when loading executable content. For interpreted
|
||||||
|
scripts, enforcement requires explicit interpreter integration using
|
||||||
|
``execveat()`` with ``AT_EXECVE_CHECK`` flag. Unlike exec syscalls that IPE
|
||||||
|
intercepts during the execution process, this mechanism needs the interpreter
|
||||||
|
to take the initiative, and existing interpreters won't be automatically
|
||||||
|
supported unless the signal call is added.
|
||||||
|
|
||||||
Threat Model
|
Threat Model
|
||||||
------------
|
------------
|
||||||
|
|
@ -806,8 +819,6 @@ A:
|
||||||
|
|
||||||
.. [#digest_cache_lsm] https://lore.kernel.org/lkml/20240415142436.2545003-1-roberto.sassu@huaweicloud.com/
|
.. [#digest_cache_lsm] https://lore.kernel.org/lkml/20240415142436.2545003-1-roberto.sassu@huaweicloud.com/
|
||||||
|
|
||||||
.. [#interpreters] There is `some interest in solving this issue <https://lore.kernel.org/lkml/20220321161557.495388-1-mic@digikod.net/>`_.
|
|
||||||
|
|
||||||
.. [#devdoc] Please see :doc:`the design docs </security/ipe>` for more on
|
.. [#devdoc] Please see :doc:`the design docs </security/ipe>` for more on
|
||||||
this topic.
|
this topic.
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue