RE: [RFC v4 0/2] WhiteEgret LSM module
We appreciate your comments.
We refine source code according to your comments.
>> 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.
>
>If existing implementations were perfect enough for everyone, we would not
>have done a lot of trial and error. ;-)
>
>>
>> My (trivial/toy/silly) module went the attribute-reading way:
>>
>> https://github.com/skx/linux-security-modules/tree/master/security/whi
>> telist
>>
>> 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
>
>Oh, checking only execve() requests? I have implemented it (using AKARI as a
>codebase) which does on-access ClamAV scan, without using
>call_usermodehelper().
>The tutorial is (written in Japanese language) available at
>http://I-love.SAKURA.ne.jp/tomoyo/scamp2017-kumaneko.html . Since
>WhiteEgret is using a daemon rather than one-time agent, I'm sure that this
>example implementation helps how to make WhiteEgret interface robust.
Thank you for introducing useful information.
>
>
>
>Here begins the feedback.
>
>(1) Please drop module exit functions, for currently it is impossible to unload
>"loadable kernel module based LSM modules".
>
>(2) Please add __init to all init functions, for it helps finding redundant
>code.
>
>(3) Please test with CONFIG_PROVE_LOCKING=y, for there is a deadlock bug
>which
>lockdep can find.
>
>(4) Please test with CONFIG_KASAN=y, for there is a use-after-free bug.
>
>(5) Please test with CONFIG_DEBUG_ATOMIC_SLEEP=y, for there is a
>sleep-in-atomic bug.
We use to fix bugs with these kernel options.
>
>(6) Please avoid redundant NULL checks.
>
>(7) Please annotate __user to userspace pointers.
>
>(8) Please do check size when copying kernel <=> user memory.
>
>(9) Setting "struct file_operations"->owner is pointless, for currently it is
>impossible to unload "loadable kernel module based LSM modules".
>
>(10) Please check the compiler output, for there is an incompatible argument
>warning.
>
>(11) Please don't try to defer pending signals. If a process got a fatal
>signal,
> the process should be able to terminate as soon as possible.
We concern whether the LSM can restart system calls in any situation.
We study behavior of restarting system calls, and we reconsider way of handling
signals.
>
>(12) Please understand when "struct file_operations"->open/release hooks are
>called,
> for current "from_task" approach is not robust (and hence the tutorial
>above).
We improve our LSM implementation to be compatible with various WEUA
implementations.
>
>
>
>A delta diff is shown below, but you don't want to apply it as-is.
>
>diff --git a/security/whiteegret/init.c b/security/whiteegret/init.c index
>b78f581..c447655 100644
>--- a/security/whiteegret/init.c
>+++ b/security/whiteegret/init.c
>@@ -23,9 +23,6 @@
>
> static int we_security_bprm_check(struct linux_binprm *bprm) {
>- if (!bprm)
>- return 0;
>-
> if (we_security_bprm_check_main(bprm) == -EACCES)
> return -EACCES;
>
>@@ -48,8 +45,6 @@ static int we_security_mmap_check(struct file *file,
>unsigned long reqprot,
> defined(CONFIG_SECURITY_WHITEEGRET_HOOK_FILE_WRITE)
> static int we_security_access_check(struct file *file, int mask) {
>- if (!file)
>- return 0;
> return we_security_access_check_main(file, mask); } #endif @@
>-58,23 +53,18 @@ static int we_security_access_check(struct file *file, int
>mask)
> defined(CONFIG_SECURITY_WHITEEGRET_HOOK_WRITE_OPEN)
> static int we_security_open_check(struct file *file) {
>- if (!file)
>- return 0;
> return we_security_open_check_main(file);
> }
> #endif
>
> #ifdef CONFIG_SECURITY_WHITEEGRET_HOOK_WRITE
>-static int we_security_rename_check(struct path *old_dir,
>+static int we_security_rename_check(const struct path *old_dir,
> struct dentry *old_dentry,
>- struct path *new_dir,
>+ const struct path *new_dir,
> struct dentry *new_dentry)
> {
> struct path new_path;
>
>- if (!new_dir)
>- return 0;
>-
> new_path.mnt = new_dir->mnt;
> new_path.dentry = new_dentry;
> return we_security_rename_check_main(_path);
>@@ -85,17 +75,11 @@ static int we_security_rename_check(struct path
>*old_dir, static int we_task_alloc_check(struct
RE: [RFC v4 0/2] WhiteEgret LSM module
We appreciate your comments.
We refine source code according to your comments.
>> 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.
>
>If existing implementations were perfect enough for everyone, we would not
>have done a lot of trial and error. ;-)
>
>>
>> My (trivial/toy/silly) module went the attribute-reading way:
>>
>> https://github.com/skx/linux-security-modules/tree/master/security/whi
>> telist
>>
>> 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
>
>Oh, checking only execve() requests? I have implemented it (using AKARI as a
>codebase) which does on-access ClamAV scan, without using
>call_usermodehelper().
>The tutorial is (written in Japanese language) available at
>http://I-love.SAKURA.ne.jp/tomoyo/scamp2017-kumaneko.html . Since
>WhiteEgret is using a daemon rather than one-time agent, I'm sure that this
>example implementation helps how to make WhiteEgret interface robust.
Thank you for introducing useful information.
>
>
>
>Here begins the feedback.
>
>(1) Please drop module exit functions, for currently it is impossible to unload
>"loadable kernel module based LSM modules".
>
>(2) Please add __init to all init functions, for it helps finding redundant
>code.
>
>(3) Please test with CONFIG_PROVE_LOCKING=y, for there is a deadlock bug
>which
>lockdep can find.
>
>(4) Please test with CONFIG_KASAN=y, for there is a use-after-free bug.
>
>(5) Please test with CONFIG_DEBUG_ATOMIC_SLEEP=y, for there is a
>sleep-in-atomic bug.
We use to fix bugs with these kernel options.
>
>(6) Please avoid redundant NULL checks.
>
>(7) Please annotate __user to userspace pointers.
>
>(8) Please do check size when copying kernel <=> user memory.
>
>(9) Setting "struct file_operations"->owner is pointless, for currently it is
>impossible to unload "loadable kernel module based LSM modules".
>
>(10) Please check the compiler output, for there is an incompatible argument
>warning.
>
>(11) Please don't try to defer pending signals. If a process got a fatal
>signal,
> the process should be able to terminate as soon as possible.
We concern whether the LSM can restart system calls in any situation.
We study behavior of restarting system calls, and we reconsider way of handling
signals.
>
>(12) Please understand when "struct file_operations"->open/release hooks are
>called,
> for current "from_task" approach is not robust (and hence the tutorial
>above).
We improve our LSM implementation to be compatible with various WEUA
implementations.
>
>
>
>A delta diff is shown below, but you don't want to apply it as-is.
>
>diff --git a/security/whiteegret/init.c b/security/whiteegret/init.c index
>b78f581..c447655 100644
>--- a/security/whiteegret/init.c
>+++ b/security/whiteegret/init.c
>@@ -23,9 +23,6 @@
>
> static int we_security_bprm_check(struct linux_binprm *bprm) {
>- if (!bprm)
>- return 0;
>-
> if (we_security_bprm_check_main(bprm) == -EACCES)
> return -EACCES;
>
>@@ -48,8 +45,6 @@ static int we_security_mmap_check(struct file *file,
>unsigned long reqprot,
> defined(CONFIG_SECURITY_WHITEEGRET_HOOK_FILE_WRITE)
> static int we_security_access_check(struct file *file, int mask) {
>- if (!file)
>- return 0;
> return we_security_access_check_main(file, mask); } #endif @@
>-58,23 +53,18 @@ static int we_security_access_check(struct file *file, int
>mask)
> defined(CONFIG_SECURITY_WHITEEGRET_HOOK_WRITE_OPEN)
> static int we_security_open_check(struct file *file) {
>- if (!file)
>- return 0;
> return we_security_open_check_main(file);
> }
> #endif
>
> #ifdef CONFIG_SECURITY_WHITEEGRET_HOOK_WRITE
>-static int we_security_rename_check(struct path *old_dir,
>+static int we_security_rename_check(const struct path *old_dir,
> struct dentry *old_dentry,
>- struct path *new_dir,
>+ const struct path *new_dir,
> struct dentry *new_dentry)
> {
> struct path new_path;
>
>- if (!new_dir)
>- return 0;
>-
> new_path.mnt = new_dir->mnt;
> new_path.dentry = new_dentry;
> return we_security_rename_check_main(_path);
>@@ -85,17 +75,11 @@ static int we_security_rename_check(struct path
>*old_dir, static int we_task_alloc_check(struct
RE: [RFC v4 0/2] WhiteEgret LSM module
Steve Kemp wrote: > 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. We also consider that it is an important point of view. We seem that it is easy to control of executions by file path rather than xattr attributes. Because the WEUA can easily get file information by file path in user space. For example, in industrial control systems (ICS), the frequency of software updates are rarer than information systems. The maintenance cost of whitelist is low in such systems. Following the NIST guideline describes importance of the whitelist execution control technology for ICS. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-167.pdf Moreover, there are various requirements depending on ICS. WhiteEgret users can implement the WEUA which is specialized for their own ICS. I guess that maintenance cost of whitelist can be decreased in ICS. > > My (trivial/toy/silly) module went the attribute-reading way: > > https://github.com/skx/linux-security-modules/tree/master/security/whi > telist > > 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 Takumi Shinya
RE: [RFC v4 0/2] WhiteEgret LSM module
Steve Kemp wrote: > 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. We also consider that it is an important point of view. We seem that it is easy to control of executions by file path rather than xattr attributes. Because the WEUA can easily get file information by file path in user space. For example, in industrial control systems (ICS), the frequency of software updates are rarer than information systems. The maintenance cost of whitelist is low in such systems. Following the NIST guideline describes importance of the whitelist execution control technology for ICS. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-167.pdf Moreover, there are various requirements depending on ICS. WhiteEgret users can implement the WEUA which is specialized for their own ICS. I guess that maintenance cost of whitelist can be decreased in ICS. > > My (trivial/toy/silly) module went the attribute-reading way: > > https://github.com/skx/linux-security-modules/tree/master/security/whi > telist > > 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 Takumi Shinya
Re: [RFC v4 0/2] WhiteEgret LSM module
Steve Kemp wrote:
> 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.
If existing implementations were perfect enough for everyone, we would not
have done a lot of trial and error. ;-)
>
> 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
Oh, checking only execve() requests? I have implemented it (using AKARI as a
codebase) which does on-access ClamAV scan, without using call_usermodehelper().
The tutorial is (written in Japanese language) available at
http://I-love.SAKURA.ne.jp/tomoyo/scamp2017-kumaneko.html . Since WhiteEgret
is using a daemon rather than one-time agent, I'm sure that this example
implementation helps how to make WhiteEgret interface robust.
Here begins the feedback.
(1) Please drop module exit functions, for currently it is impossible to unload
"loadable kernel module based LSM modules".
(2) Please add __init to all init functions, for it helps finding redundant
code.
(3) Please test with CONFIG_PROVE_LOCKING=y, for there is a deadlock bug which
lockdep can find.
(4) Please test with CONFIG_KASAN=y, for there is a use-after-free bug.
(5) Please test with CONFIG_DEBUG_ATOMIC_SLEEP=y, for there is a
sleep-in-atomic bug.
(6) Please avoid redundant NULL checks.
(7) Please annotate __user to userspace pointers.
(8) Please do check size when copying kernel <=> user memory.
(9) Setting "struct file_operations"->owner is pointless, for currently it is
impossible to unload "loadable kernel module based LSM modules".
(10) Please check the compiler output, for there is an incompatible argument
warning.
(11) Please don't try to defer pending signals. If a process got a fatal signal,
the process should be able to terminate as soon as possible.
(12) Please understand when "struct file_operations"->open/release hooks are
called,
for current "from_task" approach is not robust (and hence the tutorial
above).
A delta diff is shown below, but you don't want to apply it as-is.
diff --git a/security/whiteegret/init.c b/security/whiteegret/init.c
index b78f581..c447655 100644
--- a/security/whiteegret/init.c
+++ b/security/whiteegret/init.c
@@ -23,9 +23,6 @@
static int we_security_bprm_check(struct linux_binprm *bprm)
{
- if (!bprm)
- return 0;
-
if (we_security_bprm_check_main(bprm) == -EACCES)
return -EACCES;
@@ -48,8 +45,6 @@ static int we_security_mmap_check(struct file *file, unsigned
long reqprot,
defined(CONFIG_SECURITY_WHITEEGRET_HOOK_FILE_WRITE)
static int we_security_access_check(struct file *file, int mask)
{
- if (!file)
- return 0;
return we_security_access_check_main(file, mask);
}
#endif
@@ -58,23 +53,18 @@ static int we_security_access_check(struct file *file, int
mask)
defined(CONFIG_SECURITY_WHITEEGRET_HOOK_WRITE_OPEN)
static int we_security_open_check(struct file *file)
{
- if (!file)
- return 0;
return we_security_open_check_main(file);
}
#endif
#ifdef CONFIG_SECURITY_WHITEEGRET_HOOK_WRITE
-static int we_security_rename_check(struct path *old_dir,
+static int we_security_rename_check(const struct path *old_dir,
struct dentry *old_dentry,
- struct path *new_dir,
+ const struct path *new_dir,
struct dentry *new_dentry)
{
struct path new_path;
- if (!new_dir)
- return 0;
-
new_path.mnt = new_dir->mnt;
new_path.dentry = new_dentry;
return we_security_rename_check_main(_path);
@@ -85,17 +75,11 @@ static int we_security_rename_check(struct path *old_dir,
static int we_task_alloc_check(struct task_struct *task,
unsigned long clone_flag)
{
- if (!task)
- return 0;
-
return we_security_task_alloc_check_main(task, clone_flag);
}
static void we_task_free_check(struct task_struct *task)
{
- if (!task)
- return;
-
we_security_task_free_check_main(task);
}
#endif
@@ -137,12 +121,4 @@ static int __init we_init(void)
return 0;
}
-static void __exit we_exit(void)
-{
- we_specific_exit();
-
-
Re: [RFC v4 0/2] WhiteEgret LSM module
Steve Kemp wrote:
> 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.
If existing implementations were perfect enough for everyone, we would not
have done a lot of trial and error. ;-)
>
> 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
Oh, checking only execve() requests? I have implemented it (using AKARI as a
codebase) which does on-access ClamAV scan, without using call_usermodehelper().
The tutorial is (written in Japanese language) available at
http://I-love.SAKURA.ne.jp/tomoyo/scamp2017-kumaneko.html . Since WhiteEgret
is using a daemon rather than one-time agent, I'm sure that this example
implementation helps how to make WhiteEgret interface robust.
Here begins the feedback.
(1) Please drop module exit functions, for currently it is impossible to unload
"loadable kernel module based LSM modules".
(2) Please add __init to all init functions, for it helps finding redundant
code.
(3) Please test with CONFIG_PROVE_LOCKING=y, for there is a deadlock bug which
lockdep can find.
(4) Please test with CONFIG_KASAN=y, for there is a use-after-free bug.
(5) Please test with CONFIG_DEBUG_ATOMIC_SLEEP=y, for there is a
sleep-in-atomic bug.
(6) Please avoid redundant NULL checks.
(7) Please annotate __user to userspace pointers.
(8) Please do check size when copying kernel <=> user memory.
(9) Setting "struct file_operations"->owner is pointless, for currently it is
impossible to unload "loadable kernel module based LSM modules".
(10) Please check the compiler output, for there is an incompatible argument
warning.
(11) Please don't try to defer pending signals. If a process got a fatal signal,
the process should be able to terminate as soon as possible.
(12) Please understand when "struct file_operations"->open/release hooks are
called,
for current "from_task" approach is not robust (and hence the tutorial
above).
A delta diff is shown below, but you don't want to apply it as-is.
diff --git a/security/whiteegret/init.c b/security/whiteegret/init.c
index b78f581..c447655 100644
--- a/security/whiteegret/init.c
+++ b/security/whiteegret/init.c
@@ -23,9 +23,6 @@
static int we_security_bprm_check(struct linux_binprm *bprm)
{
- if (!bprm)
- return 0;
-
if (we_security_bprm_check_main(bprm) == -EACCES)
return -EACCES;
@@ -48,8 +45,6 @@ static int we_security_mmap_check(struct file *file, unsigned
long reqprot,
defined(CONFIG_SECURITY_WHITEEGRET_HOOK_FILE_WRITE)
static int we_security_access_check(struct file *file, int mask)
{
- if (!file)
- return 0;
return we_security_access_check_main(file, mask);
}
#endif
@@ -58,23 +53,18 @@ static int we_security_access_check(struct file *file, int
mask)
defined(CONFIG_SECURITY_WHITEEGRET_HOOK_WRITE_OPEN)
static int we_security_open_check(struct file *file)
{
- if (!file)
- return 0;
return we_security_open_check_main(file);
}
#endif
#ifdef CONFIG_SECURITY_WHITEEGRET_HOOK_WRITE
-static int we_security_rename_check(struct path *old_dir,
+static int we_security_rename_check(const struct path *old_dir,
struct dentry *old_dentry,
- struct path *new_dir,
+ const struct path *new_dir,
struct dentry *new_dentry)
{
struct path new_path;
- if (!new_dir)
- return 0;
-
new_path.mnt = new_dir->mnt;
new_path.dentry = new_dentry;
return we_security_rename_check_main(_path);
@@ -85,17 +75,11 @@ static int we_security_rename_check(struct path *old_dir,
static int we_task_alloc_check(struct task_struct *task,
unsigned long clone_flag)
{
- if (!task)
- return 0;
-
return we_security_task_alloc_check_main(task, clone_flag);
}
static void we_task_free_check(struct task_struct *task)
{
- if (!task)
- return;
-
we_security_task_free_check_main(task);
}
#endif
@@ -137,12 +121,4 @@ static int __init we_init(void)
return 0;
}
-static void __exit we_exit(void)
-{
- we_specific_exit();
-
-
Re: [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 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 >
Re: [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 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 >
