RE: [RFC 0/3] WhiteEgret LSM module

[masanobu2.koike]

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  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
> 

RE: [RFC 0/3] WhiteEgret LSM module

[masanobu2.koike]

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  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
> 

RE: [RFC 0/3] WhiteEgret LSM module

[masanobu2.koike]

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 

RE: [RFC 0/3] WhiteEgret LSM module

[masanobu2.koike]

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 

Re: [RFC 0/3] WhiteEgret LSM module

[Mehmet Kayaalp]

> On Jun 3, 2017, at 10:21 PM, Peter Dolding  wrote:
> 
> On Thu, Jun 1, 2017 at 1:36 AM, Mehmet Kayaalp
>  wrote:
>> 
>>> On May 31, 2017, at 6:59 AM, Peter Dolding  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 

Re: [RFC 0/3] WhiteEgret LSM module

[Mehmet Kayaalp]

> On Jun 3, 2017, at 10:21 PM, Peter Dolding  wrote:
> 
> On Thu, Jun 1, 2017 at 1:36 AM, Mehmet Kayaalp
>  wrote:
>> 
>>> On May 31, 2017, at 6:59 AM, Peter Dolding  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
>>> 

Re: [RFC 0/3] WhiteEgret LSM module

[Serge E. Hallyn]

Quoting Peter Dolding (oia...@gmail.com):
> On Thu, Jun 1, 2017 at 1:35 AM, Serge E. Hallyn  wrote:
> > Quoting Casey Schaufler (ca...@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

Re: [RFC 0/3] WhiteEgret LSM module

[Serge E. Hallyn]

Quoting Peter Dolding (oia...@gmail.com):
> On Thu, Jun 1, 2017 at 1:35 AM, Serge E. Hallyn  wrote:
> > Quoting Casey Schaufler (ca...@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

Re: [RFC 0/3] WhiteEgret LSM module

[Peter Dolding]

On Thu, Jun 1, 2017 at 1:35 AM, Serge E. Hallyn  wrote:
> Quoting Casey Schaufler (ca...@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

Re: [RFC 0/3] WhiteEgret LSM module

[Peter Dolding]

On Thu, Jun 1, 2017 at 1:35 AM, Serge E. Hallyn  wrote:
> Quoting Casey Schaufler (ca...@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

Re: [RFC 0/3] WhiteEgret LSM module

[Peter Dolding]

On Thu, Jun 1, 2017 at 1:36 AM, Mehmet Kayaalp
 wrote:
>
>> On May 31, 2017, at 6:59 AM, Peter Dolding  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

Re: [RFC 0/3] WhiteEgret LSM module

[Peter Dolding]

On Thu, Jun 1, 2017 at 1:36 AM, Mehmet Kayaalp
 wrote:
>
>> On May 31, 2017, at 6:59 AM, Peter Dolding  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

Re: [RFC 0/3] WhiteEgret LSM module

[Steve Kemp]

On Fri, Jun 2, 2017 at 10:00 PM, Casey Schaufler  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/

Re: [RFC 0/3] WhiteEgret LSM module

[Steve Kemp]

On Fri, Jun 2, 2017 at 10:00 PM, Casey Schaufler  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/

Re: [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/
>

Re: [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/
>

Re: [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/

Re: [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/

RE: [RFC 0/3] WhiteEgret LSM module

[masanobu2.koike]

> -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 | mj...@srcf.ucam.org

RE: [RFC 0/3] WhiteEgret LSM module

[masanobu2.koike]

> -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 | mj...@srcf.ucam.org

Re: [RFC 0/3] WhiteEgret LSM module

[Serge E. Hallyn]

Quoting Casey Schaufler (ca...@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.

Re: [RFC 0/3] WhiteEgret LSM module

[Serge E. Hallyn]

Quoting Casey Schaufler (ca...@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.

Re: [RFC 0/3] WhiteEgret LSM module

[Mehmet Kayaalp]

> On May 31, 2017, at 6:59 AM, Peter Dolding  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

Re: [RFC 0/3] WhiteEgret LSM module

[Mehmet Kayaalp]

> On May 31, 2017, at 6:59 AM, Peter Dolding  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

Re: [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?

Re: [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?

Re: [RFC 0/3] WhiteEgret LSM module

[Peter Dolding]

On Wed, May 31, 2017 at 6:50 AM, Matthew Garrett  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 

Re: [RFC 0/3] WhiteEgret LSM module

[Peter Dolding]

On Wed, May 31, 2017 at 6:50 AM, Matthew Garrett  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 

Re: [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 | mj...@srcf.ucam.org

Re: [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 | mj...@srcf.ucam.org

Re: [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 

Re: [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