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(&new_path);
>@@ -85,17 +75,11 @@ static int we_security_rename_check(struct path
>*old_dir, static int we_task_alloc_check(struct task_s
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 v3 0/2] WhiteEgret LSM module
> 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
RE: [RFC v3 0/2] WhiteEgret LSM module
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: owner-linux-security-mod...@vger.kernel.org [mailto:owner-linux-security-mod...@vger.kernel.org] On Behalf Of Serge E. Hallyn Sent: Monday, April 2, 2018 5:08 AM To: koike masanobu(小池 正修 ＴＤＳＬ （ＩＳＥＣ）［ＳＥＣ運］) Cc: jmor...@namei.org; se...@hallyn.com; linux-security-mod...@vger.kernel.org; linux-kernel@vger.kernel.org Subject: Re: [RFC v3 0/2] WhiteEgret LSM module Quoting Masanobu Koike (masanobu2.ko...@toshiba.co.jp): ... > 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
