[RFC 0/3] WhiteEgret LSM module

[RFC 0/3] WhiteEgret LSM module

[Masanobu Koike]

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 to stop the execution of
malicious code and other unauthorized software.
The whitelisting-type execution control works best in the
execution environments that are not changed for a long time,
for example, servers and control devices in industrial
control systems. This RFC provides a whitelisting-type
execution control implementation WhiteEgret.

Features of WhiteEgret

- Easier initial setup
All you have to do is to make a whitelist. The whitelist
shall contain all components that should be permitted
execution in the host. When we assume that the host does
not have malicious code in initial state, we just register
all executable components in the host to the whitelist.
The whitelist of WhiteEgret is assumed to contain at least
an absolute path and a hash value of the permitted
executable components.
WhiteEgret does not require policy generation which,
in general, is difficult and takes time for users.

- Shorten downtime in system updating
According to system update, we should update the whitelist.
It will take a short time. Consequently, system downtime
due to security configuration update can be reduced.

- Less restriction on operational environment
WhiteEgret does not depend on a file system, or on TPM.
Thus WhiteEgret has less restriction on operating environment.

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 an
absolute path of the executable component to the WEUA.
Then the WEUA is expected to work as follows.
The WEUA sees if the absolute path is contained in the whitelist.
If it exists, the WEUA compares a hash value of the executable
component indicated by the absolute path 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 has two interface to communicate between kernel
space and user space: netlink and device driver. Although we
plan on using netlink, kernel Oops rarely happens when we use
netlink. Because we have not determined the cause yet,
we provide another communication method using device driver.
(See ToDo #1)

The process of a WEUA is registered to WhiteEgret when it starts.
The CAP_NET_ADMIN capability is required for a process to
register to WhiteEgret. Once some process is registered,
after that, WhiteEgret rejects registration from the other
process by PID.
At the moment, authentication of WEUA by WhiteEgret at
registration has not implemented yet. Current authentication
function returns always "authenticated". (See ToDo #2)

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 and
CONFIG_DEFAULT_SECURITY_WHITEEGRET=y (or pass
"security=whiteegret" on kernel's command line).

If you want to use device driver for communication between
kernel space and user space, then you are also required to
enable option CONFIG_SECURITY_WHITEEGRET_DRIVER.

ToDo
 1. Bug fix of communication when using netlink.
 2. Authentication of WEUA by WhiteEgret when the WEUA
    is registered to WhiteEgret.

Masanobu Koike (3):
  WhiteEgret: Add WhiteEgret core functions.
  WhiteEgret: Add device driver.
  WhiteEgret: Add an example of user application.

 drivers/Kconfig                         |   2 +
 drivers/Makefile                        |   1 +
 drivers/security/Kconfig                |   1 +
 drivers/security/Makefile               |   1 +
 drivers/security/whiteegret/Kconfig     |  10 +
 drivers/security/whiteegret/Makefile    |   3 +
 drivers/security/whiteegret/we_driver.c | 295 ++++++++++++++++++++++++
 drivers/security/whiteegret/we_driver.h |  32 +++
 samples/Kconfig                         |   6 +
 samples/Makefile                        |   2 +-
 samples/whiteegret/Makefile             |  25 +++
 samples/whiteegret/checkwl.c            |  80 +++++++
 samples/whiteegret/checkwl.h            |  29 +++
 samples/whiteegret/gennl.c              | 232 +++++++++++++++++++
 samples/whiteegret/gennl_user.h         |  32 +++
 samples/whiteegret/main.c               | 234 +++++++++++++++++++
 security/Kconfig                        |   7 +-
 security/Makefile                       |   2 +
 security/whiteegret/Kconfig             |  21 ++
 security/whiteegret/Makefile            |   7 +
 security/whiteegret/auth.c              |  19 ++
 security/whiteegret/auth.h              |  12 +
 security/whiteegret/dd_com.c            |  79 +++++++
 security/whiteegret/dd_com.h            |  19 ++
 security/whiteegret/gennl.c             | 382 ++++++++++++++++++++++++++++++++
 security/whiteegret/gennl.h             |  32 +++
 security/whiteegret/gennl_common.h      |  43 ++++
 security/whiteegret/init.c              |  69 ++++++
 security/whiteegret/main.c              | 340 ++++++++++++++++++++++++++++
 security/whiteegret/print_msg.h         |  19 ++
 security/whiteegret/request.c           | 248 +++++++++++++++++++++
 security/whiteegret/request.h           |  79 +++++++
 security/whiteegret/returntoexec.h      |  14 ++
 security/whiteegret/we.h                |  72 ++++++
 security/whiteegret/we_common.h         |  19 ++
 35 files changed, 2466 insertions(+), 2 deletions(-)
 create mode 100644 drivers/security/Kconfig
 create mode 100644 drivers/security/Makefile
 create mode 100644 drivers/security/whiteegret/Kconfig
 create mode 100644 drivers/security/whiteegret/Makefile
 create mode 100644 drivers/security/whiteegret/we_driver.c
 create mode 100644 drivers/security/whiteegret/we_driver.h
 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/gennl.c
 create mode 100644 samples/whiteegret/gennl_user.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/auth.c
 create mode 100644 security/whiteegret/auth.h
 create mode 100644 security/whiteegret/dd_com.c
 create mode 100644 security/whiteegret/dd_com.h
 create mode 100644 security/whiteegret/gennl.c
 create mode 100644 security/whiteegret/gennl.h
 create mode 100644 security/whiteegret/gennl_common.h
 create mode 100644 security/whiteegret/init.c
 create mode 100644 security/whiteegret/main.c
 create mode 100644 security/whiteegret/print_msg.h
 create mode 100644 security/whiteegret/request.c
 create mode 100644 security/whiteegret/request.h
 create mode 100644 security/whiteegret/returntoexec.h
 create mode 100644 security/whiteegret/we.h
 create mode 100644 security/whiteegret/we_common.h

-- 
2.9.3


--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Casey Schaufler]

On 5/30/2017 4:11 AM, Masanobu Koike 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 to stop the execution of
> malicious code and other unauthorized software.
> The whitelisting-type execution control works best in the
> execution environments that are not changed for a long time,
> for example, servers and control devices in industrial
> control systems. This RFC provides a whitelisting-type
> execution control implementation WhiteEgret.

Why is this better than setting the ownership and mode bits
appropriately on your programs and libraries?

Beyond that, I'm pretty sure you could do this with AppArmor.
If you're only doing the set-up once I think you can do this
with SELinux (the proponents of SELinux can tell you how).
I know you can do it with Smack. Why is this scheme better?

>
> Features of WhiteEgret
>
> - Easier initial setup
> All you have to do is to make a whitelist.

In practice whitelists are built by starting with everything
and deleting items until things stop working, then putting
them back. Whitelists are theoretically great, but very difficult
to build and maintain in the real world.

>  The whitelist
> shall contain all components that should be permitted
> execution in the host. When we assume that the host does
> not have malicious code in initial state, we just register
> all executable components in the host to the whitelist.
> The whitelist of WhiteEgret is assumed to contain at least
> an absolute path and a hash value of the permitted
> executable components.
> WhiteEgret does not require policy generation which,
> in general, is difficult and takes time for users.

Creating a proper whitelist is every bit as difficult as
some aspects of policy generation. Granted, it's easier
than generating SELinux policy or a proper Smack configuration,
but the protection is a subset of what those systems provide. 

> - Shorten downtime in system updating
> According to system update, we should update the whitelist.
> It will take a short time. Consequently, system downtime
> due to security configuration update can be reduced.
>
> - Less restriction on operational environment
> WhiteEgret does not depend on a file system, or on TPM.
> Thus WhiteEgret has less restriction on operating environment.
>
> 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.

Really, really bad idea. One visit from the OOM killer and
your system is dead. One user space exploit and your system
is compromised. Performance will be dreadful. Deadlocks, races
and stalls, oh my!

> 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 an
> absolute path of the executable component to the WEUA.
> Then the WEUA is expected to work as follows.
> The WEUA sees if the absolute path is contained in the whitelist.
> If it exists, the WEUA compares a hash value of the executable
> component indicated by the absolute path 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".

How do you address symlinks, mount points, containers and chroot?

> WhiteEgret has two interface to communicate between kernel
> space and user space: netlink and device driver. Although we
> plan on using netlink, kernel Oops rarely happens when we use
> netlink. Because we have not determined the cause yet,
> we provide another communication method using device driver.
> (See ToDo #1)
>
> The process of a WEUA is registered to WhiteEgret when it starts.
> The CAP_NET_ADMIN capability is required for a process to
> register to WhiteEgret. Once some process is registered,
> after that, WhiteEgret rejects registration from the other
> process by PID.
> At the moment, authentication of WEUA by WhiteEgret at
> registration has not implemented yet. Current authentication
> function returns always "authenticated". (See ToDo #2)
>
> 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 and
> CONFIG_DEFAULT_SECURITY_WHITEEGRET=y (or pass
> "security=whiteegret" on kernel's command line).
>
> If you want to use device driver for communication between
> kernel space and user space, then you are also required to
> enable option CONFIG_SECURITY_WHITEEGRET_DRIVER.
>
> ToDo
>  1. Bug fix of communication when using netlink.
>  2. Authentication of WEUA by WhiteEgret when the WEUA
>     is registered to WhiteEgret.
>
> Masanobu Koike (3):
>   WhiteEgret: Add WhiteEgret core functions.
>   WhiteEgret: Add device driver.
>   WhiteEgret: Add an example of user application.
>
>  drivers/Kconfig                         |   2 +
>  drivers/Makefile                        |   1 +
>  drivers/security/Kconfig                |   1 +
>  drivers/security/Makefile               |   1 +
>  drivers/security/whiteegret/Kconfig     |  10 +
>  drivers/security/whiteegret/Makefile    |   3 +
>  drivers/security/whiteegret/we_driver.c | 295 ++++++++++++++++++++++++
>  drivers/security/whiteegret/we_driver.h |  32 +++
>  samples/Kconfig                         |   6 +
>  samples/Makefile                        |   2 +-
>  samples/whiteegret/Makefile             |  25 +++
>  samples/whiteegret/checkwl.c            |  80 +++++++
>  samples/whiteegret/checkwl.h            |  29 +++
>  samples/whiteegret/gennl.c              | 232 +++++++++++++++++++
>  samples/whiteegret/gennl_user.h         |  32 +++
>  samples/whiteegret/main.c               | 234 +++++++++++++++++++
>  security/Kconfig                        |   7 +-
>  security/Makefile                       |   2 +
>  security/whiteegret/Kconfig             |  21 ++
>  security/whiteegret/Makefile            |   7 +
>  security/whiteegret/auth.c              |  19 ++
>  security/whiteegret/auth.h              |  12 +
>  security/whiteegret/dd_com.c            |  79 +++++++
>  security/whiteegret/dd_com.h            |  19 ++
>  security/whiteegret/gennl.c             | 382 ++++++++++++++++++++++++++++++++
>  security/whiteegret/gennl.h             |  32 +++
>  security/whiteegret/gennl_common.h      |  43 ++++
>  security/whiteegret/init.c              |  69 ++++++
>  security/whiteegret/main.c              | 340 ++++++++++++++++++++++++++++
>  security/whiteegret/print_msg.h         |  19 ++
>  security/whiteegret/request.c           | 248 +++++++++++++++++++++
>  security/whiteegret/request.h           |  79 +++++++
>  security/whiteegret/returntoexec.h      |  14 ++
>  security/whiteegret/we.h                |  72 ++++++
>  security/whiteegret/we_common.h         |  19 ++
>  35 files changed, 2466 insertions(+), 2 deletions(-)
>  create mode 100644 drivers/security/Kconfig
>  create mode 100644 drivers/security/Makefile
>  create mode 100644 drivers/security/whiteegret/Kconfig
>  create mode 100644 drivers/security/whiteegret/Makefile
>  create mode 100644 drivers/security/whiteegret/we_driver.c
>  create mode 100644 drivers/security/whiteegret/we_driver.h
>  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/gennl.c
>  create mode 100644 samples/whiteegret/gennl_user.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/auth.c
>  create mode 100644 security/whiteegret/auth.h
>  create mode 100644 security/whiteegret/dd_com.c
>  create mode 100644 security/whiteegret/dd_com.h
>  create mode 100644 security/whiteegret/gennl.c
>  create mode 100644 security/whiteegret/gennl.h
>  create mode 100644 security/whiteegret/gennl_common.h
>  create mode 100644 security/whiteegret/init.c
>  create mode 100644 security/whiteegret/main.c
>  create mode 100644 security/whiteegret/print_msg.h
>  create mode 100644 security/whiteegret/request.c
>  create mode 100644 security/whiteegret/request.h
>  create mode 100644 security/whiteegret/returntoexec.h
>  create mode 100644 security/whiteegret/we.h
>  create mode 100644 security/whiteegret/we_common.h
>

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Matthew Garrett]

On Tue, May 30, 2017 at 08:11:57PM +0900, Masanobu Koike wrote:
> 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 to stop the execution of
> malicious code and other unauthorized software.
> The whitelisting-type execution control works best in the
> execution environments that are not changed for a long time,
> for example, servers and control devices in industrial
> control systems. This RFC provides a whitelisting-type
> execution control implementation WhiteEgret.

There's a few assumptions made here:

1) The system isn't subject to any form of offline attack. If it is, the 
attacker can simply replace either the whitelist agent or any of the 
executables.
2) The system contains no whitelisted executables that will execute 
arbitrary code. This means not shipping perl or python.
3) None of the whitelisted applications on the system will misbehave if 
fed invalid input.
4) It's impossible for a user to ptrace() any other process after it's 
been executed, and simply inject new code.

(3) is especially awkward. If you're implementing this as an LSM then 
you're giving up on being able to use any of the other LSMs to protect 
you against this - a vulnerability in a single application bypasses your 
entire security model.

The kernel already has support for application whitelisting in the form 
of IMA appraisal. All you need to do is sign the apps that you want 
whitelisted and then load a policy at runtime that enforces appraisal. 
Anything that's unsigned will then fail to execute. This deals with (1) 
(assuming that you load the policy from something that's validated 
earlier in the boot process), is no worse with respect to (2), and still 
allows you to use SELinux or Apparmor to mitigate (3) and (4). You also 
gain additional reliability by not having the system fail in the event 
of a bug in the whitelisting agent causing it to crash.

I think it would be helpful to have more details of exactly what 
circumstances this is intended to be used in and then figure out whether 
there's any way to use existing kernel functionality to provide the same 
benefits.
-- 
Matthew Garrett | mjg59 at srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Peter Dolding]

On Wed, May 31, 2017 at 6:50 AM, Matthew Garrett <mjg59@google.com> wrote:
> On Tue, May 30, 2017 at 08:11:57PM +0900, Masanobu Koike wrote:
>> 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 to stop the execution of
>> malicious code and other unauthorized software.
>> The whitelisting-type execution control works best in the
>> execution environments that are not changed for a long time,
>> for example, servers and control devices in industrial
>> control systems. This RFC provides a whitelisting-type
>> execution control implementation WhiteEgret.
>
> There's a few assumptions made here:
>
> 1) The system isn't subject to any form of offline attack. If it is, the
> attacker can simply replace either the whitelist agent or any of the
> executables.
> 2) The system contains no whitelisted executables that will execute
> arbitrary code. This means not shipping perl or python.
> 3) None of the whitelisted applications on the system will misbehave if
> fed invalid input.
> 4) It's impossible for a user to ptrace() any other process after it's
> been executed, and simply inject new code.
>
> (3) is especially awkward. If you're implementing this as an LSM then
> you're giving up on being able to use any of the other LSMs to protect
> you against this - a vulnerability in a single application bypasses your
> entire security model.
>
> The kernel already has support for application whitelisting in the form
> of IMA appraisal. All you need to do is sign the apps that you want
> whitelisted and then load a policy at runtime that enforces appraisal.
> Anything that's unsigned will then fail to execute. This deals with (1)
> (assuming that you load the policy from something that's validated
> earlier in the boot process), is no worse with respect to (2), and still
> allows you to use SELinux or Apparmor to mitigate (3) and (4). You also
> gain additional reliability by not having the system fail in the event
> of a bug in the whitelisting agent causing it to crash.
>
> I think it would be helpful to have more details of exactly what
> circumstances this is intended to be used in and then figure out whether
> there's any way to use existing kernel functionality to provide the same
> benefits.
>
Number 1 we need to split the idea of signed and whitelisted.   IMA is
signed should not be confused with white-listed.    You will find
policies stating whitelist and signed as two different things.

Like you see here in Australian government policy there is another
thing called whitelisted.
https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm
Matthew Garrett you might want to call IMA whitelisting Australian
government for one does not agree.  IMA is signed.   The difference
between signed and white-listed is you might have signed a lot more
than what a particular system is white-listed to allowed used.

WhiteEgret has another fault that even if you locked the program
against ptrace there is another problem.   The idea of passing
application name and path than checking that is valid does not in fact
work a fd(File descriptor)need to be passed.

1) kernel sends request to open file1 has fd.
2) update updates file1
3) WEUA WhiteEgret opens and checks path and name resulting in reading
update file1 and approves it.
4) kernel runs non updated file1.

By passing a fd to the userspace you can be user that the kernel and
userspace are on the same page.

We do need a whitelisting solution in the kernel.   To allow for the
different government requirements a userspace application may be a
consideration.   Whitelisting agent crashing need to include the
option of kernel panic in that case.  Others many wish for the option
to reload the whitelisting agent and the possibility of the
white-listing agent sending here is a new agent run that then
terminate me.

The feature need to include in it name whitelisting or just like the
Australian Department of Defence other parties will mark Linux has not
having this feature.

Security policy enforcement is the title given to SELinux and
Apparmor.   As they do more than a simple list of what is approved to
run and what is not approved to run.     There are two forms of
whitelist we need to worry about per application/service and system
wide.   Preferable whitelist, Security Policy
enforcement(SELInux/Apparmor) and signed(IMA) all need to be able to
successfully run at the same time.

The big thing that has to stop is suggesting using Security Policy
enforcement or IMA as whitelisting that is not what major end
consumers of this are asking for.

Now I am only referring to how Australian government will title the
Linux kernel features and the requirement they are looking for.   I
would not be surprised if other governments are the same in their
titling of Linux features.

I see this idea of this patch kinda on the right path but
implementation is very lacking.    Maybe system wide whitelist
features should be linked to IMA as a user-space callable program of
course that program does not override signed or not signed approval
only checks against what ever the current whitelist is.

Whitelist is program name/path and checksum/s.   If the file any more
than that is now not a Whitelist but a Security Policy Enforcement or
signing.   Whitelist and blacklists are meant to be simple things.
This is also why IMA fails and is signed to too complete to be a basic
Whitelist.

Whitelists expected systemwide and per user/service.   So the ability
to connect a whitelist to a namespace could possibly be used to do the
per user/service.

Reason for the userspace is old Linux system and government policy
says some new checksum the old Linux kernel does not have.   Of course
this issue could possible be handled another way allowing the Linux
kernel to use assigned userspace programs for checksumming.   Remember
what we make to today will be old at some point in the future running
10+ year old system is nothing new to governments.

Yes inverted policy was not in this module being a blacklist due to
using a userspace application it would not be hard for the userspace
program to be set to approve everything bar what it had on a black
list..

So design need to include option to use both whitelist and blacklist
with these being simple filenames and path with checksums.   We need
something in Linux kernel documentation covering whitelist and
blacklist with them being simple.

Peter Dolding.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Casey Schaufler]

On 5/31/2017 3:59 AM, Peter Dolding wrote:
> ...
>
> Like you see here in Australian government policy there is another
> thing called whitelisted.
> https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm
> Matthew Garrett you might want to call IMA whitelisting Australian
> government for one does not agree.  IMA is signed.   The difference
> between signed and white-listed is you might have signed a lot more
> than what a particular system is white-listed to allowed used.
>
To be clear, I'm all for a security module to support this policy.
As the explicit requirement is for a whitelist, as opposed to allowing
for a properly configured system*, you can't use any of the existing
technologies to meet it. This kind of thing** is why we have a LSM
infrastructure.

Unfortunately, the implementation proposed has very serious issues.
You can't do access control from userspace. You can't count on
identifying programs strictly by pathname. It's much more complicated
than it needs to be for the task.

Suggestion:

Create an security module that looks for the attribute

	security.WHITELISTED

on things being executed/mmapped and denys it if the attribute isn't
present. Create a program (whitelistd) that reads /etc/whitelist.conf
and scans the system to ensure that only things on the list have the
attribute. Or, download the list into the kernel and only allow the
attribute to be set on files on the list. That's harder, what with
rename, links, symlinks, mounts, chroot and containers. I wrote a
security module (Datastate) back in 2010 that did much the same thing
for a different purpose.

Please, don't give up because of negative initial feedback. Believe
it or not, the community (well, most of us, anyway) is willing to
help to the extent possible.


---
*  A script that checks for the 'x' mode bit on files should suffice.
** A return to the heady days of the Orange Book?

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Serge E. Hallyn]

Quoting Casey Schaufler (casey at schaufler-ca.com):
> 
> 
> On 5/31/2017 3:59 AM, Peter Dolding wrote:
> > ...
> >
> > Like you see here in Australian government policy there is another
> > thing called whitelisted.
> > https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm
> > Matthew Garrett you might want to call IMA whitelisting Australian
> > government for one does not agree.  IMA is signed.   The difference
> > between signed and white-listed is you might have signed a lot more
> > than what a particular system is white-listed to allowed used.
> >
> To be clear, I'm all for a security module to support this policy.
> As the explicit requirement is for a whitelist, as opposed to allowing
> for a properly configured system*, you can't use any of the existing
> technologies to meet it. This kind of thing** is why we have a LSM
> infrastructure.
> 
> Unfortunately, the implementation proposed has very serious issues.
> You can't do access control from userspace. You can't count on
> identifying programs strictly by pathname. It's much more complicated
> than it needs to be for the task.
> 
> Suggestion:
> 
> Create an security module that looks for the attribute
> 
> 	security.WHITELISTED

Bonus, you can have EVM verify the validity of these xattrs, and
IMA verify the interity of the file itself.
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Mehmet Kayaalp]

> On May 31, 2017, at 6:59 AM, Peter Dolding <oiaohm@gmail.com> wrote:
> 
> Number 1 we need to split the idea of signed and whitelisted.   IMA is
> signed should not be confused with white-listed.    You will find
> policies stating whitelist and signed as two different things.

IMA-appraisal can do both. If the securtiy.ima extended attribute
of the file is a hash and not a signature, then it is whitelisting.

> Like you see here in Australian government policy there is another
> thing called whitelisted.
> https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm
> Matthew Garrett you might want to call IMA whitelisting Australian
> government for one does not agree.  IMA is signed.   The difference
> between signed and white-listed is you might have signed a lot more
> than what a particular system is white-listed to allowed used.

I doubt the Australian government is an authority on Linux features.
IMA-appraisal can be set to "fix" mode with a boot parameter. If the 
policy covers what you want to whitelist (e.g. files opened by user x), 
and then when those files are accessed, the kernel writes out the hash. 
Then, you can switch to "enforce" mode to allow only files with hashes.

Also, you can achieve the same thing by signing all whitelisted 
files and add the certificate to .ima keyring and throwing away the
signing key.

> The feature need to include in it name whitelisting or just like the
> Australian Department of Defence other parties will mark Linux has not
> having this feature.

I guess we need to advertise IMA-appraisal better.

> Whitelist is program name/path and checksum/s.   If the file any more
> than that is now not a Whitelist but a Security Policy Enforcement or
> signing.   Whitelist and blacklists are meant to be simple things.
> This is also why IMA fails and is signed to too complete to be a basic
> Whitelist.

When you work out all the little details, you arrive at IMA-appraisal.
You have to consider how the scheme is bootstrapped and how it
is protected against the root. IMA-appraisal either relies on a boot
parameter and write-once policy, or the trusted keyrings.

> Peter Dolding.

Mehmet

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[masanobu2.koike at toshiba.co.jp]

> -----Original Message-----
> 
> On Tue, May 30, 2017 at 08:11:57PM +0900, Masanobu Koike wrote:
> > 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 to stop the execution of
> > malicious code and other unauthorized software.
> > The whitelisting-type execution control works best in the
> > execution environments that are not changed for a long time,
> > for example, servers and control devices in industrial
> > control systems. This RFC provides a whitelisting-type
> > execution control implementation WhiteEgret.
> 
> There's a few assumptions made here:
> 
> 1) The system isn't subject to any form of offline attack. If it is, the
> attacker can simply replace either the whitelist agent or any of the
> executables.
> 2) The system contains no whitelisted executables that will execute
> arbitrary code. This means not shipping perl or python.
> 3) None of the whitelisted applications on the system will misbehave if
> fed invalid input.
> 4) It's impossible for a user to ptrace() any other process after it's
> been executed, and simply inject new code.
> 
> (3) is especially awkward. If you're implementing this as an LSM then
> you're giving up on being able to use any of the other LSMs to protect
> you against this - a vulnerability in a single application bypasses your
> entire security model.
> 
> The kernel already has support for application whitelisting in the form
> of IMA appraisal. All you need to do is sign the apps that you want
> whitelisted and then load a policy at runtime that enforces appraisal.
> Anything that's unsigned will then fail to execute. This deals with (1)
> (assuming that you load the policy from something that's validated
> earlier in the boot process), is no worse with respect to (2), and still
> allows you to use SELinux or Apparmor to mitigate (3) and (4). You also
> gain additional reliability by not having the system fail in the event
> of a bug in the whitelisting agent causing it to crash.
> 
> I think it would be helpful to have more details of exactly what
> circumstances this is intended to be used in and then figure out whether
> there's any way to use existing kernel functionality to provide the same
> benefits.

Thank you for a lot of comments and suggestions.

We assume a system whose execution environment cannot be
changed for a long time. It includes industrial control
systems, and control devices are main target.
Owners of these systems do not want to change their execution
environments, including kernel update, for fear that the
systems might not run correctly.
As time goes on, new security vulnerabilities might be found
and new malwares might be allowed to access such devices.
We want to prohibit unknown executable objects from executing
on the devices.

Moreover, such devices, in general, continue to do the same
tasks for many years. Namely, executable objects for the tasks
are not changed for a long time.
So permitting only pre-determined executable objects to execute,
whitelisting execution control, is suitable for such devices.

I will reply later on technical aspects.

Thanks,

Masanobu Koike

> --
> Matthew Garrett | mjg59 at srcf.ucam.org



--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Steve Kemp]

> Create an security module that looks for the attribute

For what it is worth I thought this seemed like an interesting project
for a beginner, so I did just that.  I wrote up the experience here:

https://blog.steve.fi/so_i_accidentally_wrote_a_linux_security_module.html

In short it was a very simple and clean approach, which I think is
hard to get wrong.  The only part I need to work on some more is the
difference between `user` and `security` attributes.

Steve
--
https://steve.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Casey Schaufler]

On 6/2/2017 10:39 AM, Steve Kemp wrote:
>> Create an security module that looks for the attribute
> For what it is worth I thought this seemed like an interesting project
> for a beginner, so I did just that.  I wrote up the experience here:
>
> https://blog.steve.fi/so_i_accidentally_wrote_a_linux_security_module.html
>
> In short it was a very simple and clean approach, which I think is
> hard to get wrong.  The only part I need to work on some more is the
> difference between `user` and `security` attributes.

A 'user' attribute can be set by the file owner. A 'security'
attribute requires privilege. SELinux and Smack use 'security'
attributes to prevent users from mucking with them. You need
to create module hooks for manipulating them, including

	inode_init_security
	inode_setxattr
	inode_post_setxattr
	inode_removexattr
	inode_getsecurity
	inode_listsecurity
	inode_setsecurity
	d_instantiate



>
> Steve
> --
> https://steve.fi/
>

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Steve Kemp]

On Fri, Jun 2, 2017 at 10:00 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:

> A 'user' attribute can be set by the file owner. A 'security'
> attribute requires privilege. SELinux and Smack use 'security'
> attributes to prevent users from mucking with them. You need
> to create module hooks for manipulating them,

That's nice and clear, I appreciate you explaining it to me.

I'll have a go at updating my toy LSM to do that shortly.  For
reference I placed the patch here, but don't expect to submit it
formally to lkmk as it was more an interesting learning experience:

https://github.com/skx/linux/pull/1

(I did take the time to rename it from steve_lsm.c to whitelist_lsm.c
though, lest I look too vain!)

Steve
-- 
https://steve.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Peter Dolding]

On Thu, Jun 1, 2017 at 1:36 AM, Mehmet Kayaalp
<mkayaalp@linux.vnet.ibm.com> wrote:
>
>> On May 31, 2017, at 6:59 AM, Peter Dolding <oiaohm@gmail.com> wrote:
>>
>> Number 1 we need to split the idea of signed and whitelisted.   IMA is
>> signed should not be confused with white-listed.    You will find
>> policies stating whitelist and signed as two different things.
>
> IMA-appraisal can do both. If the securtiy.ima extended attribute
> of the file is a hash and not a signature, then it is whitelisting.

This this point you straight up fail.   This is no long classes a
whitelist.  Its now an extended attribute checksum.

IMA with proper whitelist support were whitelist is a file allows IMA
to have hashs and so on stored in that file so removing the need for
the filesystem where IMA being used to have extended attributes.

Second for this is being able to open up 1 file and see what is approved.


>
>> Like you see here in Australian government policy there is another
>> thing called whitelisted.
>> https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm
>> Matthew Garrett you might want to call IMA whitelisting Australian
>> government for one does not agree.  IMA is signed.   The difference
>> between signed and white-listed is you might have signed a lot more
>> than what a particular system is white-listed to allowed used.
>
> I doubt the Australian government is an authority on Linux features.
> IMA-appraisal can be set to "fix" mode with a boot parameter. If the
> policy covers what you want to whitelist (e.g. files opened by user x),
> and then when those files are accessed, the kernel writes out the hash.
> Then, you can switch to "enforce" mode to allow only files with hashes.

Question does this feature support booting the system in different
modes giving different accessible files.

The feature says whitelist but is fact to tick the box is lists.   So
booted into standard mode has one lot of applications and booted into
repair mode has another lot of applications and so on with this being
achieved by choosing different whitelist files at boot.
>
> Also, you can achieve the same thing by signing all whitelisted
> files and add the certificate to .ima keyring and throwing away the
> signing key.

This here is signed nothing to-do with whitelist.    This is using
signing to hack round not having a proper whitelist feature so this
can never ticks the box.
>
>> The feature need to include in it name whitelisting or just like the
>> Australian Department of Defence other parties will mark Linux has not
>> having this feature.
>
> I guess we need to advertise IMA-appraisal better.

They have looked that and it fails.   Because IMA currently is lacking
the feature.

I do see that whitelist and blacklist file support added to IMA so IMA
does not need extended attribute file systems and for those who want
all the setting in one file would be a good thing.

UUID of the file system could be included in path to file in whitelist.
>
>> Whitelist is program name/path and checksum/s.   If the file any more
>> than that is now not a Whitelist but a Security Policy Enforcement or
>> signing.   Whitelist and blacklists are meant to be simple things.
>> This is also why IMA fails and is signed to too complete to be a basic
>> Whitelist.
>
> When you work out all the little details, you arrive at IMA-appraisal.
> You have to consider how the scheme is bootstrapped and how it
> is protected against the root. IMA-appraisal either relies on a boot
> parameter and write-once policy, or the trusted keyrings.
>
Here you have gone wrong.

You are presume whitelist has to be protected against root.   A signed
whitelist does have to be protected against root.   Unsigned whitelist
in fact being alterable by those with privilege is expected..

You don't have firewall rules always protected against root right.
Unsigned whitelists are in the same camp.

Also other mistakes is when they are looking for whitelist feature
they are also looking for blacklist feature.

IMA features need to apply just as much to containers as they do to
the complete system.   This is where things get tricky.   Putting
entries in filesystem xattr for every service you have risks running
you out of file system xattr space.

>From my point view the missing system wide whitelist and blacklist
file support is a defect of IMA that is not design at this stage to be
able to function without filesystem xattr as soon as remove the means
to use xattr design IMA you are forced to implement whitelist file at
least..

Also I see it as a weakness in IMA that it cannot be done on a per
container base and this is also mostly likely due to over file system
dependence.

I am not saying that IMA xattr usage has to be removed but it should
not be the only option IMA has.

Peter Dolding
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Peter Dolding]

On Thu, Jun 1, 2017 at 1:35 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> Quoting Casey Schaufler (casey at schaufler-ca.com):
>>
>>
>> On 5/31/2017 3:59 AM, Peter Dolding wrote:
>> > ...
>> >
>> > Like you see here in Australian government policy there is another
>> > thing called whitelisted.
>> > https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm
>> > Matthew Garrett you might want to call IMA whitelisting Australian
>> > government for one does not agree.  IMA is signed.   The difference
>> > between signed and white-listed is you might have signed a lot more
>> > than what a particular system is white-listed to allowed used.
>> >
>> To be clear, I'm all for a security module to support this policy.
>> As the explicit requirement is for a whitelist, as opposed to allowing
>> for a properly configured system*, you can't use any of the existing
>> technologies to meet it. This kind of thing** is why we have a LSM
>> infrastructure.
>>
>> Unfortunately, the implementation proposed has very serious issues.
>> You can't do access control from userspace. You can't count on
>> identifying programs strictly by pathname. It's much more complicated
>> than it needs to be for the task.
>>
>> Suggestion:
>>
>> Create an security module that looks for the attribute
>>
>>       security.WHITELISTED
>
> Bonus, you can have EVM verify the validity of these xattrs, and
> IMA verify the interity of the file itself.

Complete fail.   You have to think of a whitelist as a list you give
to a security at a gate.

Shot-gunned all over the file system that you have to search down what
is approved is not acceptable.

I should be more clear you need a whitelist file to tick the box.
Where you can open up 1 file and see everything that is on the
approved list.   Same with blacklist.   Think of it like a list of
invited guests given to a security guard at a door.   You can check
who is invited by look at that list.     Attribute is like saying if
the person has X id let them in and going to the guard at the door to
see who is let in is not going to help you.

Of course just because the guard at door is letting people on the list
in does not mean they are not checking ids as well.   This is not an
either or issue this is an add a feature.

So whitelist file and Attribute in production usage function way
differently.   You don't want to have to scan a complete filesystem
all the time looking for stray set attributes.

Whitelist and Blacklisting fits into IMA not LSM really.    Because
you need to be able to use other LSM at the same time as
white/blacklists.

EVM and attributes  they are so easy to use that implement
whitelist/blacklist files has not be done.  Including means to sign
whitelist files to prevent modification when required.

So what both of you are suggest is not the right item to tick the box
to claim Linux has whitelist support.

Linux has hacks to implement whitelist support not properly whitelist
support that is functional in the right way.

Whitelist functional in the right way look in 1 location know what is set.

Also IMA support for containers is kind required supporting
whitelist/blacklist files because setting everything into attribute
can become very impractical.

So this is something that is missing.

Peter Dolding
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Serge E. Hallyn]

Quoting Peter Dolding (oiaohm at gmail.com):
> On Thu, Jun 1, 2017 at 1:35 AM, Serge E. Hallyn <serge@hallyn.com> wrote:
> > Quoting Casey Schaufler (casey at schaufler-ca.com):
> >>
> >>
> >> On 5/31/2017 3:59 AM, Peter Dolding wrote:
> >> > ...
> >> >
> >> > Like you see here in Australian government policy there is another
> >> > thing called whitelisted.
> >> > https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm
> >> > Matthew Garrett you might want to call IMA whitelisting Australian
> >> > government for one does not agree.  IMA is signed.   The difference
> >> > between signed and white-listed is you might have signed a lot more
> >> > than what a particular system is white-listed to allowed used.
> >> >
> >> To be clear, I'm all for a security module to support this policy.
> >> As the explicit requirement is for a whitelist, as opposed to allowing
> >> for a properly configured system*, you can't use any of the existing
> >> technologies to meet it. This kind of thing** is why we have a LSM
> >> infrastructure.
> >>
> >> Unfortunately, the implementation proposed has very serious issues.
> >> You can't do access control from userspace. You can't count on
> >> identifying programs strictly by pathname. It's much more complicated
> >> than it needs to be for the task.
> >>
> >> Suggestion:
> >>
> >> Create an security module that looks for the attribute
> >>
> >>       security.WHITELISTED
> >
> > Bonus, you can have EVM verify the validity of these xattrs, and
> > IMA verify the interity of the file itself.
> 
> Complete fail.   You have to think of a whitelist as a list you give
> to a security at a gate.
> 
> Shot-gunned all over the file system that you have to search down what
> is approved is not acceptable.
>
> I should be more clear you need a whitelist file to tick the box.

So you do what SELinux does.  You offer a list of 'at-boot' files which a
relabeling program goes over and measures.  But when it is time to check if
someone is allowed ot run a program, you check what is stored with the file
being run.  The security.WHITELISTED xattr :)  Not the list.  It was good
enough for CAPP and LSPP, should be good enough for your org.

If that doesn't suffice, then you will not be able to tick the box, and you
should go back to the people who drew the box and have them update their
requirements.  They're usually pretty interested.

> Where you can open up 1 file and see everything that is on the
> approved list.   Same with blacklist.   Think of it like a list of

That '1 file' is just a user interface/toolset issue.  It doesn't restrict
how the kernel implements it.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[Mehmet Kayaalp]

> On Jun 3, 2017, at 10:21 PM, Peter Dolding <oiaohm@gmail.com> wrote:
> 
> On Thu, Jun 1, 2017 at 1:36 AM, Mehmet Kayaalp
> <mkayaalp@linux.vnet.ibm.com> wrote:
>> 
>>> On May 31, 2017, at 6:59 AM, Peter Dolding <oiaohm@gmail.com> wrote:
>>> 
>>> Number 1 we need to split the idea of signed and whitelisted.   IMA is
>>> signed should not be confused with white-listed.    You will find
>>> policies stating whitelist and signed as two different things.
>> 
>> IMA-appraisal can do both. If the securtiy.ima extended attribute
>> of the file is a hash and not a signature, then it is whitelisting.
> 
> This this point you straight up fail.   This is no long classes a
> whitelist.  Its now an extended attribute checksum.

I think you have a limited view of what constitutes a whitelist. The xattr
approach has the (subjective) benefit of not having a centralized list.
You are describing NetBSD veriexec [1].  

> IMA with proper whitelist support were whitelist is a file allows IMA
> to have hashs and so on stored in that file so removing the need for
> the filesystem where IMA being used to have extended attributes.

I agree with this point. Perhaps IMA could benefit from a fallback
mechanism for filesystems without xattr support. But since other LSMs
make heavy use of xattr as well, we should also pursue adding xattr
support.

> Second for this is being able to open up 1 file and see what is approved.

This is also a nice feature of a central list. But what people don't like about
this might be the mount point, symlink, chroot etc.

>>> Like you see here in Australian government policy there is another
>>> thing called whitelisted.
>>> https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.htm
>>> Matthew Garrett you might want to call IMA whitelisting Australian
>>> government for one does not agree.  IMA is signed.   The difference
>>> between signed and white-listed is you might have signed a lot more
>>> than what a particular system is white-listed to allowed used.
>> 
>> I doubt the Australian government is an authority on Linux features.
>> IMA-appraisal can be set to "fix" mode with a boot parameter. If the
>> policy covers what you want to whitelist (e.g. files opened by user x),
>> and then when those files are accessed, the kernel writes out the hash.
>> Then, you can switch to "enforce" mode to allow only files with hashes.
> 
> Question does this feature support booting the system in different
> modes giving different accessible files.

Different policies and keys are possible, but probably not as easy to manage
as having several whitelist files. 

> The feature says whitelist but is fact to tick the box is lists.   So
> booted into standard mode has one lot of applications and booted into
> repair mode has another lot of applications and so on with this being
> achieved by choosing different whitelist files at boot.

Our goal is not exactly ticking boxes for compliance etc. This, again,
could be achieved by perhaps having different keys. 

>> Also, you can achieve the same thing by signing all whitelisted
>> files and add the certificate to .ima keyring and throwing away the
>> signing key.
> 
> This here is signed nothing to-do with whitelist.    This is using
> signing to hack round not having a proper whitelist feature so this
> can never ticks the box.

I wouldn't call it a hack. If you are using a key for the sole purpose of
signing everything in a whitelist, then the verification of a signature
becomes: "is this in my whitelist?". It is an indirection. One can treat
each key as a different whitelist. Again, not ticking boxes. Considering
attacks and how to protect the integrity of the system.

>>> The feature need to include in it name whitelisting or just like the
>>> Australian Department of Defence other parties will mark Linux has not
>>> having this feature.
>> 
>> I guess we need to advertise IMA-appraisal better.
> 
> They have looked that and it fails.   Because IMA currently is lacking
> the feature.
> 
> I do see that whitelist and blacklist file support added to IMA so IMA
> does not need extended attribute file systems and for those who want
> all the setting in one file would be a good thing.
> 
> UUID of the file system could be included in path to file in whitelist.

I'm not sure who looked at what and what was the lacking feature. But
what is the threat model, why wouldn't IMA-appraisal work in terms of 
security? If there is a compelling reason for having a whitelist file, 
maybe we should think of an IMA policy mechanism for this. IMA policy 
can specify files by owner/user, filesystem type/UUID, LSM labels etc. 
If we could also say "files listed in this file", I guess it would provide the
usability "benefit" of a single file.  

>>> Whitelist is program name/path and checksum/s.   If the file any more
>>> than that is now not a Whitelist but a Security Policy Enforcement or
>>> signing.   Whitelist and blacklists are meant to be simple things.
>>> This is also why IMA fails and is signed to too complete to be a basic
>>> Whitelist.
>> 
>> When you work out all the little details, you arrive at IMA-appraisal.
>> You have to consider how the scheme is bootstrapped and how it
>> is protected against the root. IMA-appraisal either relies on a boot
>> parameter and write-once policy, or the trusted keyrings.
>> 
> Here you have gone wrong.
> 
> You are presume whitelist has to be protected against root.   A signed
> whitelist does have to be protected against root.   Unsigned whitelist
> in fact being alterable by those with privilege is expected..
> 
> You don't have firewall rules always protected against root right.
> Unsigned whitelists are in the same camp.

Yes, I assumed the protection should not be easy to turn off. But that
is a valid assumption for many situations.

> Also other mistakes is when they are looking for whitelist feature
> they are also looking for blacklist feature.

If there is a single whitelist and the enforcement prevents access to
any other file, do you still need a blacklist? You could just remove it
from the whitelist maybe? 

> IMA features need to apply just as much to containers as they do to
> the complete system.   This is where things get tricky.   Putting
> entries in filesystem xattr for every service you have risks running
> you out of file system xattr space.

I agree with the first two sentences, but you lost me at the third. 
What do you mean by every service? Are they different containers,
using the same file? Because, if they are different files, then it is not
a problem of xattr space.

> From my point view the missing system wide whitelist and blacklist
> file support is a defect of IMA that is not design at this stage to be
> able to function without filesystem xattr as soon as remove the means
> to use xattr design IMA you are forced to implement whitelist file at
> least..

Yes, xattr is a design choice of IMA. It has the "benefit" of having a
distributed whitelist. 

> Also I see it as a weakness in IMA that it cannot be done on a per
> container base and this is also mostly likely due to over file system
> dependence.

Containers make everything more difficult. The absolute path approach 
has the mount point dependence.  

> I am not saying that IMA xattr usage has to be removed but it should
> not be the only option IMA has.

Agreed.

[1] https://wiki.netbsd.org/guide/veriexec/

Mehmet

--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[masanobu2.koike at toshiba.co.jp]

Casey Schaufler wrote:
> On 5/30/2017 4:11 AM, Masanobu Koike 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 to stop the execution of
> > malicious code and other unauthorized software.
> > The whitelisting-type execution control works best in the
> > execution environments that are not changed for a long time,
> > for example, servers and control devices in industrial
> > control systems. This RFC provides a whitelisting-type
> > execution control implementation WhiteEgret.
> 
> Why is this better than setting the ownership and mode bits
> appropriately on your programs and libraries?
> 
> Beyond that, I'm pretty sure you could do this with AppArmor.
> If you're only doing the set-up once I think you can do this
> with SELinux (the proponents of SELinux can tell you how).
> I know you can do it with Smack. Why is this scheme better?

Thank you for your feedback.

We assume a system whose execution environment cannot be
changed for a long time. It includes industrial control
systems, and control devices are main target.
Although operators for such systems are experts for the
industrial controllers, they are often not familiar with
information systems or OSes. So it's worth providing
a mechanism they can manage.

Writing down whitelisting like access control is as follows.
  subjects - all
  objects - each permitted executable component
  permission - yes
So operators have to know only name of permitted executable
components to make a whitelist or change it. Reducing the
number of items to be set helps operators manage the systems.

However, we assume the following for the above systems:
(1) Root is not compromised.
(2) The host does not have malicious code in initial state.
(3) Using a whitelist and a WEUA requires root privilege.
Relaxing these assumptions are welcome.

> 
> >
> > Features of WhiteEgret
> >
> > - Easier initial setup
> > All you have to do is to make a whitelist.
> 
> In practice whitelists are built by starting with everything
> and deleting items until things stop working, then putting
> them back. Whitelists are theoretically great, but very difficult
> to build and maintain in the real world.

It is true that managing whitelist for information systems
is a hard task because their execution environments are
changed frequently.
On the other hand, for such devices that continue to do the same
tasks for many years, we can use the same whitelist for a long
time once the whitelist is established. When the host does not
have malicious code in initial state, we can just register all
executable components in the host to the whitelist.

> 
> >  The whitelist
> > shall contain all components that should be permitted
> > execution in the host. When we assume that the host does
> > not have malicious code in initial state, we just register
> > all executable components in the host to the whitelist.
> > The whitelist of WhiteEgret is assumed to contain at least
> > an absolute path and a hash value of the permitted
> > executable components.
> > WhiteEgret does not require policy generation which,
> > in general, is difficult and takes time for users.
> 
> Creating a proper whitelist is every bit as difficult as
> some aspects of policy generation. Granted, it's easier
> than generating SELinux policy or a proper Smack configuration,
> but the protection is a subset of what those systems provide.
> 
> > - Shorten downtime in system updating
> > According to system update, we should update the whitelist.
> > It will take a short time. Consequently, system downtime
> > due to security configuration update can be reduced.
> >
> > - Less restriction on operational environment
> > WhiteEgret does not depend on a file system, or on TPM.
> > Thus WhiteEgret has less restriction on operating environment.
> >
> > 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.
> 
> Really, really bad idea. One visit from the OOM killer and
> your system is dead. One user space exploit and your system
> is compromised. Performance will be dreadful. Deadlocks, races
> and stalls, oh my!

Thank you for the pointing out. We also recognized similar kind
of problems. It is true that some mechanisms are necessary to
save systems from WEUA failures.
But there are some ways in user space to deal with problems
caused by user space application. For example, cgroups prevents
OOM killer from killing WEUA by separating WEUA memory space
form other applications. 

> 
> > 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 an
> > absolute path of the executable component to the WEUA.
> > Then the WEUA is expected to work as follows.
> > The WEUA sees if the absolute path is contained in the whitelist.
> > If it exists, the WEUA compares a hash value of the executable
> > component indicated by the absolute path 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".
> 
> How do you address symlinks, mount points, containers and chroot?

Because symlinks are resolved before WhiteEgret sends it to the WEUA,
execution control works normally according to the linked executable
component is included in the whitelist or not.

We doubt that mount or chroot commands on a device we assume
(such as industrial control device) are issued during operation
because they change operational environments. But if it happens,
then we have to prepare a whitelist assuming directory structure
of mount points or chrooted directories, or reconstruct a whitelist
after mounting or chrooting.

We cannot deal with containers at the moment as you pointed out.

Thank you.

Masanobu Koike

> 
> > WhiteEgret has two interface to communicate between kernel
> > space and user space: netlink and device driver. Although we
> > plan on using netlink, kernel Oops rarely happens when we use
> > netlink. Because we have not determined the cause yet,
> > we provide another communication method using device driver.
> > (See ToDo #1)
> >
> > The process of a WEUA is registered to WhiteEgret when it starts.
> > The CAP_NET_ADMIN capability is required for a process to
> > register to WhiteEgret. Once some process is registered,
> > after that, WhiteEgret rejects registration from the other
> > process by PID.
> > At the moment, authentication of WEUA by WhiteEgret at
> > registration has not implemented yet. Current authentication
> > function returns always "authenticated". (See ToDo #2)
> >
> > 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 and
> > CONFIG_DEFAULT_SECURITY_WHITEEGRET=y (or pass
> > "security=whiteegret" on kernel's command line).
> >
> > If you want to use device driver for communication between
> > kernel space and user space, then you are also required to
> > enable option CONFIG_SECURITY_WHITEEGRET_DRIVER.
> >
> > ToDo
> >  1. Bug fix of communication when using netlink.
> >  2. Authentication of WEUA by WhiteEgret when the WEUA
> >     is registered to WhiteEgret.
> >
> > Masanobu Koike (3):
> >   WhiteEgret: Add WhiteEgret core functions.
> >   WhiteEgret: Add device driver.
> >   WhiteEgret: Add an example of user application.
> >
> >  drivers/Kconfig                         |   2 +
> >  drivers/Makefile                        |   1 +
> >  drivers/security/Kconfig                |   1 +
> >  drivers/security/Makefile               |   1 +
> >  drivers/security/whiteegret/Kconfig     |  10 +
> >  drivers/security/whiteegret/Makefile    |   3 +
> >  drivers/security/whiteegret/we_driver.c | 295
> ++++++++++++++++++++++++
> >  drivers/security/whiteegret/we_driver.h |  32 +++
> >  samples/Kconfig                         |   6 +
> >  samples/Makefile                        |   2 +-
> >  samples/whiteegret/Makefile             |  25 +++
> >  samples/whiteegret/checkwl.c            |  80 +++++++
> >  samples/whiteegret/checkwl.h            |  29 +++
> >  samples/whiteegret/gennl.c              | 232 +++++++++++++++++++
> >  samples/whiteegret/gennl_user.h         |  32 +++
> >  samples/whiteegret/main.c               | 234 +++++++++++++++++++
> >  security/Kconfig                        |   7 +-
> >  security/Makefile                       |   2 +
> >  security/whiteegret/Kconfig             |  21 ++
> >  security/whiteegret/Makefile            |   7 +
> >  security/whiteegret/auth.c              |  19 ++
> >  security/whiteegret/auth.h              |  12 +
> >  security/whiteegret/dd_com.c            |  79 +++++++
> >  security/whiteegret/dd_com.h            |  19 ++
> >  security/whiteegret/gennl.c             | 382
> ++++++++++++++++++++++++++++++++
> >  security/whiteegret/gennl.h             |  32 +++
> >  security/whiteegret/gennl_common.h      |  43 ++++
> >  security/whiteegret/init.c              |  69 ++++++
> >  security/whiteegret/main.c              | 340
> ++++++++++++++++++++++++++++
> >  security/whiteegret/print_msg.h         |  19 ++
> >  security/whiteegret/request.c           | 248 +++++++++++++++++++++
> >  security/whiteegret/request.h           |  79 +++++++
> >  security/whiteegret/returntoexec.h      |  14 ++
> >  security/whiteegret/we.h                |  72 ++++++
> >  security/whiteegret/we_common.h         |  19 ++
> >  35 files changed, 2466 insertions(+), 2 deletions(-)
> >  create mode 100644 drivers/security/Kconfig
> >  create mode 100644 drivers/security/Makefile
> >  create mode 100644 drivers/security/whiteegret/Kconfig
> >  create mode 100644 drivers/security/whiteegret/Makefile
> >  create mode 100644 drivers/security/whiteegret/we_driver.c
> >  create mode 100644 drivers/security/whiteegret/we_driver.h
> >  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/gennl.c
> >  create mode 100644 samples/whiteegret/gennl_user.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/auth.c
> >  create mode 100644 security/whiteegret/auth.h
> >  create mode 100644 security/whiteegret/dd_com.c
> >  create mode 100644 security/whiteegret/dd_com.h
> >  create mode 100644 security/whiteegret/gennl.c
> >  create mode 100644 security/whiteegret/gennl.h
> >  create mode 100644 security/whiteegret/gennl_common.h
> >  create mode 100644 security/whiteegret/init.c
> >  create mode 100644 security/whiteegret/main.c
> >  create mode 100644 security/whiteegret/print_msg.h
> >  create mode 100644 security/whiteegret/request.c
> >  create mode 100644 security/whiteegret/request.h
> >  create mode 100644 security/whiteegret/returntoexec.h
> >  create mode 100644 security/whiteegret/we.h
> >  create mode 100644 security/whiteegret/we_common.h
> >
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[RFC 0/3] WhiteEgret LSM module

[masanobu2.koike at toshiba.co.jp]

Hi Mehmet,

Thank you for your suggestion to use IMA appraisal.
I'm sorry for the delay in replying to you. I'm studying IMA appraisal.

There is something I don't understand yet. Could you please teach me
the following items?
We assume that "fixing" has already finished and that IMA appraisal
is running in "enforce" mode.

- I have a question for a procedure of labeling and appraising a new
or updated executable file.
Suppose that we want to create a new executable file (included in policy)
and make it be measured and appraised.
Then what kind of procedure should I do?
Similarly, how do I update appraised file to be continuously permitted
to execute?

- When we copy (cp command with -a option) or move an appraised executable
file to somewhere, is the copied or moved executable file permitted to
execute as well?

- (related to the above question) What kind of data is hashed to security.ima?

Thanks in advance,

Masanobu Koike

> -----Original Message-----
> 
> > On May 31, 2017, at 6:59 AM, Peter Dolding <oiaohm@gmail.com> wrote:
> >
> > Number 1 we need to split the idea of signed and whitelisted.   IMA is
> > signed should not be confused with white-listed.    You will find
> > policies stating whitelist and signed as two different things.
> 
> IMA-appraisal can do both. If the securtiy.ima extended attribute
> of the file is a hash and not a signature, then it is whitelisting.
> 
> > Like you see here in Australian government policy there is another
> > thing called whitelisted.
> >
> https://www.asd.gov.au/publications/protect/top_4_mitigations_linux.ht
> m
> > Matthew Garrett you might want to call IMA whitelisting Australian
> > government for one does not agree.  IMA is signed.   The difference
> > between signed and white-listed is you might have signed a lot more
> > than what a particular system is white-listed to allowed used.
> 
> I doubt the Australian government is an authority on Linux features.
> IMA-appraisal can be set to "fix" mode with a boot parameter. If the
> policy covers what you want to whitelist (e.g. files opened by user x),
> and then when those files are accessed, the kernel writes out the hash.
> Then, you can switch to "enforce" mode to allow only files with hashes.
> 
> Also, you can achieve the same thing by signing all whitelisted
> files and add the certificate to .ima keyring and throwing away the
> signing key.
> 
> > The feature need to include in it name whitelisting or just like the
> > Australian Department of Defence other parties will mark Linux has not
> > having this feature.
> 
> I guess we need to advertise IMA-appraisal better.
> 
> > Whitelist is program name/path and checksum/s.   If the file any more
> > than that is now not a Whitelist but a Security Policy Enforcement or
> > signing.   Whitelist and blacklists are meant to be simple things.
> > This is also why IMA fails and is signed to too complete to be a basic
> > Whitelist.
> 
> When you work out all the little details, you arrive at IMA-appraisal.
> You have to consider how the scheme is bootstrapped and how it
> is protected against the root. IMA-appraisal either relies on a boot
> parameter and write-once policy, or the trusted keyrings.
> 
> > Peter Dolding.
> 
> Mehmet
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html