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".
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.
Assumptions and ToDos
At this stage, WhiteEgret assumes the following.
Relaxing these assumptions are future works.
- Root is not compromised. And using a whitelist and a WEUA
requires root privilege.
- WEUA is reliable.
- It is allowed for scripting languages, e.g., Perl or Python,
to read arbitrary scripts and to execute them.
The patchset is also available in our github repo:
https://github.com/whiteegret/whiteegret
---
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.
Masanobu Koike (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 | 57 ++++++++
samples/whiteegret/checkwl.h | 26 ++++
samples/whiteegret/main.c | 86 +++++++++++
security/Kconfig | 1 +
security/Makefile | 2 +
security/whiteegret/Kconfig | 11 ++
security/whiteegret/Makefile | 2 +
security/whiteegret/init.c | 72 ++++++++++
security/whiteegret/main.c | 255 +++++++++++++++++++++++++++++++++
security/whiteegret/request.c | 151 ++++++++++++++++++++
security/whiteegret/request.h | 52 +++++++
security/whiteegret/we.h | 66 +++++++++
security/whiteegret/we_fs.c | 284 +++++++++++++++++++++++++++++++++++++
security/whiteegret/we_fs.h | 23 +++
security/whiteegret/we_fs_common.h | 36 +++++
18 files changed, 1145 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.14.1
Quoting Masanobu Koike ([email protected]):
...
> Assumptions and ToDos
>
> At this stage, WhiteEgret assumes the following.
> Relaxing these assumptions are future works.
> - Root is not compromised. And using a whitelist and a WEUA
> requires root privilege.
> - WEUA is reliable.
> - It is allowed for scripting languages, e.g., Perl or Python,
> to read arbitrary scripts and to execute them.
Hi,
regardling the last one, do you have a plan for handling it?
I am one of developers of WhiteEgret.
> regardling the last one, do you have a plan for handling it?
Yes, we have a plan to release WhiteEgret v4 patch with a WEUA sample of access control for script programs.
The latest WhiteEgret cannot control script programs since script files read by an interpreter are not hooked by the execve system call.
We consider that script programs can be controlled by controlling the files inputted by interpreters, accordingly.
We consider that the control can be realized using the read system call hooking.
Now, we are developing WhiteEgret with the read system call hooking and WEUA which controls the script files to be read to interpreters using information from the read system call hooking and white list.
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Serge E. Hallyn
Sent: Monday, April 2, 2018 5:08 AM
To: koike masanobu($B>.CS(B $B@5=$(B $B#T#D#S#L(B $B!J#I#S#E#C!K!N#S#E#C1?!O(B) <[email protected]>
Cc: [email protected]; [email protected]; [email protected]; [email protected]
Subject: Re: [RFC v3 0/2] WhiteEgret LSM module
Quoting Masanobu Koike ([email protected]):
...
> Assumptions and ToDos
>
> At this stage, WhiteEgret assumes the following.
> Relaxing these assumptions are future works.
> - Root is not compromised. And using a whitelist and a WEUA requires
> root privilege.
> - WEUA is reliable.
> - It is allowed for scripting languages, e.g., Perl or Python, to read
> arbitrary scripts and to execute them.
Hi,
regardling the last one, do you have a plan for handling it?
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoting [email protected] ([email protected]):
> I am one of developers of WhiteEgret.
>
> > regardling the last one, do you have a plan for handling it?
> Yes, we have a plan to release WhiteEgret v4 patch with a WEUA sample of access control for script programs.
Do you have a target date for posting that?
> The latest WhiteEgret cannot control script programs since script files read by an interpreter are not hooked by the execve system call.
> We consider that script programs can be controlled by controlling the files inputted by interpreters, accordingly.
> We consider that the control can be realized using the read system call hooking.
So you have a design for being able to differentiate the interpreters reading
versus reading with the intent to execute? With or without their help?
> Now, we are developing WhiteEgret with the read system call hooking and WEUA which controls the script files to be read to interpreters using information from the read system call hooking and white list.
-serge
> Do you have a target date for posting that?
Yes, we have the target date. We will submit WhiteEgret v4 by September.
> So you have a design for being able to differentiate the interpreters
> reading versus reading with the intent to execute?
> With or without their help?
We will provide WEUA sample to be able to control a script program with WhiteEgret v4.
Our WEUA sample does not identify whether to read or to read with the intent to execute.
The sample has some restrictions.
We consider that the restrictions can be resolved by implementing additional functions for WEUA.
It is an implementation-dependent matter.
Howerver, we are sure that the restrictions are acceptable for many applications.
We would like to discuss about them with WhiteEgret v4 patch!
-----Original Message-----
> I am one of developers of WhiteEgret.
>
> > regardling the last one, do you have a plan for handling it?
> Yes, we have a plan to release WhiteEgret v4 patch with a WEUA sample of access control for script programs.
Do you have a target date for posting that?
> The latest WhiteEgret cannot control script programs since script files read by an interpreter are not hooked by the execve system call.
> We consider that script programs can be controlled by controlling the files inputted by interpreters, accordingly.
> We consider that the control can be realized using the read system call hooking.
So you have a design for being able to differentiate the interpreters reading versus reading with the intent to execute? With or without their help?
> Now, we are developing WhiteEgret with the read system call hooking and WEUA which controls the script files to be read to interpreters using information from the read system call hooking and white list.
-serge