lkml.org 
[lkml]   [2018]   [Oct]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [RFC v4 0/2] WhiteEgret LSM module
This is an interesting idea, and an evolution since the initial
approach which was submitted based upon xattr attributes. I still
find the idea of using attributes simpler to manage though, since
they're easy to add, and audit for.

I suspect the biggest objection to this module is that maintaining a
whitelist at all is often impractical.

My (trivial/toy/silly) module went the attribute-reading way:

https://github.com/skx/linux-security-modules/tree/master/security/whitelist

For a completely crazy take upon the idea of userspace decisions
though you can laugh at my attempt here:

https://github.com/skx/linux-security-modules/tree/master/security/can-exec

I callback to userspace for every decision, via
call_usermodehelper_setup. The crazy part is that it actually works
at all!

Steve
On Fri, Oct 19, 2018 at 8:37 AM Shinya Takumi
<shinya1.takumi@toshiba.co.jp> wrote:
>
> WhiteEgret is an LSM to simply provide a whitelisting-type
> execution control.
>
> An execution-whitelist, simply called whitelist, is a list
> of executable components (e.g., applications, libraries)
> that are approved to run on a host. The whitelist is used
> to decide whether executable components are permitted to
> execute or not. This mechanism can stop an execution of
> unknown software, so it helps stop the execution of
> malicious code and other unauthorized software.
>
> It is important to maintain a whitelist properly according to
> the execution environments. Managing whitelists for information
> systems is a difficult task because their environments are
> changed frequently. On the other hand, for such devices that
> continue to do the same tasks for a certain period of time,
> we can use the same whitelist for the period once the whitelist
> is established. Thus the whitelisting-type execution control
> works best in such execution environments. Examples of the above
> execution environments include control devices in industrial
> control systems.
>
> Although the number of changing whitelists is not so large,
> it is necessary to change them according to a system life cycle
> or each phase of system operations. There is a requirement to
> change whitelists with the system operations continued because
> they often cannot easily be stopped. For example, such cases
> include temporarily allowing maintenance programs for maintenance
> or troubleshooting purposes while running the systems.
>
> WhiteEgret is aiming at satisfying the above requirement.
> WhiteEgret adopts a model that a whitelist is managed in user space.
> Namely, WhiteEgret assumes that a privileged user manages a whitelist
> in user space. This makes it possible to change the whitelist while
> running the systems.
>
> Mechanism of WhiteEgret
>
> WhiteEgret requires a user application called WhiteEgret User
> Application (WEUA, for short). WhiteEgret utilizes the
> bprm_check_security hook and the mmap_file hook.
> WhiteEgret asks WEUA whether an executable component hooked
> by the above hooks is permitted to execute or not.
> If the response from the WEUA is "permit", then WhiteEgret
> continues to process the executable component. If the response
> is "not permit", then WhiteEgret returns an error and blocks
> the execution of the executable component.
> The bprm_check_security hook is triggered by execve system
> call, so execution by almost all executable components are
> hooked by the hook. However, because shared objects do not
> invoke execve system call, WhiteEgret utilizes the mmap_file
> hook to hook the memory mapping by a shared object.
> Thus WhiteEgret ignores the mmap_file hook caused by
> non-executable and by executable which calls execve system call.
>
> To ask the permission to a WEUA, WhiteEgret sends the
> absolute path, the inode number and the device number of the
> executable component to the WEUA.
> Then the WEUA is expected to work as follows.
> The WEUA sees if the tuple of the absolute path and/or the inode
> number and/or the device number is contained in the whitelist.
> If it exists, the WEUA compares a hash value of the executable
> component indicated by the absolute path (and/or the inode number
> and/or device number) with that in the whitelist to see whether
> the executable component is changed or not after the whitelist is
> made. The WEUA returns "permit" if both tests are passed,
> otherwise returns "not permit".
>
> WhiteEgret v4 is also able to control for script execution. Some
> LSM hooks (file_open/file_permission/task_alloc/task_free) are
> added. Kernel configs are required to enable the hooks.
>
> Most of interpreters open script files to execute. Therefore
> WhiteEgret hooks for reading or opening a file. Then WhiteEgret
> asks the WEUA whether an execution of the script is permitted to
> execute or not. WhiteEgret is able to choose a hook entry for
> execution control between file_open or file_permission.
>
> Hook entries of task_alloc and task_free are used to control
> exections of script effectively. Some interpreters forks child
> processes to execte script files, so the WEUA managed a process
> family of an interpter by bprm_check_security, task_alloc and
> task_free.
>
> To use WhiteEgret
>
> Users have to prepare a whitelist and a WEUA to use WhiteEgret.
> A sample WEUA is involved in samples/whiteegret/.
>
> To enable WhiteEgret, you are required to build the kernel using
> normal procedures with CONFIG_SECURITY_WHITEEGRET=y.
>
> Additionally, SECURITY_WHITEEGRET_INTERPRETER=y option is
> required to enable to control script executions.
> And SECURITY_WHITEEGRET_WRITE=y option is also required to
> detect of writing script files.
>
> The patchset is also available in our github repo:
> https://github.com/whiteegret/whiteegret
>
> ---
> Changes in v4:
> - Add LSM hooks (file_open/file_permission/task_alloc/task_free)
> to control for script execution. Kernel configs are required
> to enable the hooks.
> - Modify the data struct for kernel space and user space
> communication.
>
> Changes in v3:
> - Change to a minor LSM module.
>
> Changes in v2:
> - Change communication method between kernel space and user space
> from netlink to device driver, and device driver utilizes not LKM
> but securityfs.
> - Add inode number and device number to information of executable
> component sent from kernel space to user space.
> - Fix bugs regarding to locks during kernel space and user space
> communication.
> - Change return value from -EPERM to -EACCES when the execution of
> an executable component is denied.
>
> Shinya Takumi (2):
> WhiteEgret: Add WhiteEgret core functions.
> WhiteEgret: Add an example of user application.
>
> samples/Kconfig | 6 +
> samples/Makefile | 2 +-
> samples/whiteegret/Makefile | 14 ++
> samples/whiteegret/checkwl.c | 215 +++++++++++++++++
> samples/whiteegret/checkwl.h | 33 +++
> samples/whiteegret/main.c | 119 ++++++++++
> security/Kconfig | 1 +
> security/Makefile | 2 +
> security/whiteegret/Kconfig | 82 +++++++
> security/whiteegret/Makefile | 2 +
> security/whiteegret/init.c | 148 ++++++++++++
> security/whiteegret/main.c | 466 +++++++++++++++++++++++++++++++++++++
> security/whiteegret/request.c | 98 ++++++++
> security/whiteegret/request.h | 47 ++++
> security/whiteegret/we.h | 72 ++++++
> security/whiteegret/we_fs.c | 269 +++++++++++++++++++++
> security/whiteegret/we_fs.h | 23 ++
> security/whiteegret/we_fs_common.h | 60 +++++
> 18 files changed, 1658 insertions(+), 1 deletion(-)
> create mode 100644 samples/whiteegret/Makefile
> create mode 100644 samples/whiteegret/checkwl.c
> create mode 100644 samples/whiteegret/checkwl.h
> create mode 100644 samples/whiteegret/main.c
> create mode 100644 security/whiteegret/Kconfig
> create mode 100644 security/whiteegret/Makefile
> create mode 100644 security/whiteegret/init.c
> create mode 100644 security/whiteegret/main.c
> create mode 100644 security/whiteegret/request.c
> create mode 100644 security/whiteegret/request.h
> create mode 100644 security/whiteegret/we.h
> create mode 100644 security/whiteegret/we_fs.c
> create mode 100644 security/whiteegret/we_fs.h
> create mode 100644 security/whiteegret/we_fs_common.h
>
> --
> 2.7.4
>

\
 
 \ /
  Last update: 2018-10-21 14:09    [W:0.136 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site