Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks

On Sat, Apr 7, 2018 at 2:31 AM, Casey Schaufler <ca...@schaufler-ca.com> wrote: > On 4/5/2018 9:12 PM, Peter Dolding wrote: >> On Fri, Apr 6, 2018 at 11:31 AM, Sargun Dhillon <sar...@sargun.me> wrote: >>> >>> On Thu, Apr 5, 2018 at 9:29 AM, Casey Schau

Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks

On Sat, Apr 7, 2018 at 2:31 AM, Casey Schaufler wrote: > On 4/5/2018 9:12 PM, Peter Dolding wrote: >> On Fri, Apr 6, 2018 at 11:31 AM, Sargun Dhillon wrote: >>> >>> On Thu, Apr 5, 2018 at 9:29 AM, Casey Schaufler >>> wrote: >>>> On 4/5/2018 3

Re: [GIT PULL] Kernel lockdown for secure boot

ch remove the EFI interrogation patches and work with UEFI to fix it properly. Hacking around these UEFI defects means we will end up being stuck with them and the system still not being properly secured. Peter Dolding

Re: [GIT PULL] Kernel lockdown for secure boot

ch remove the EFI interrogation patches and work with UEFI to fix it properly. Hacking around these UEFI defects means we will end up being stuck with them and the system still not being properly secured. Peter Dolding

Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks

On Fri, Apr 6, 2018 at 11:31 AM, Sargun Dhillon <sar...@sargun.me> wrote: > > > On Thu, Apr 5, 2018 at 9:29 AM, Casey Schaufler <ca...@schaufler-ca.com> > wrote: >> >> On 4/5/2018 3:31 AM, Peter Dolding wrote: >> > On Thu, Apr 5, 2018 at 7:55 PM, Ig

Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks

On Fri, Apr 6, 2018 at 11:31 AM, Sargun Dhillon wrote: > > > On Thu, Apr 5, 2018 at 9:29 AM, Casey Schaufler > wrote: >> >> On 4/5/2018 3:31 AM, Peter Dolding wrote: >> > On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa >> > wrote: >> >> On 01

Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks

On Thu, Apr 5, 2018 at 9:34 PM, Igor Stoppa <igor.sto...@huawei.com> wrote: > On 05/04/18 13:31, Peter Dolding wrote: >> On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa <igor.sto...@huawei.com> wrote: >> There is a shade of grey between something being a security hazard and

Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks

On Thu, Apr 5, 2018 at 9:34 PM, Igor Stoppa wrote: > On 05/04/18 13:31, Peter Dolding wrote: >> On Thu, Apr 5, 2018 at 7:55 PM, Igor Stoppa wrote: >> There is a shade of grey between something being a security hazard and >> something being a useful feature. > > Mayb

Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks

ally. With all the different LSM options how do application/distribution makers validate all the different LSM configurations effectively is a question that does need to be answered. In answering this question allowing this form of compromised security as a option might be quite a valid move. Peter Dolding

Re: [PATCH v4 0/1] Safe LSM (un)loading, and immutable hooks

ent LSM options how do application/distribution makers validate all the different LSM configurations effectively is a question that does need to be answered. In answering this question allowing this form of compromised security as a option might be quite a valid move. Peter Dolding

Re: [GIT PULL] Kernel lockdown for secure boot

On Thu, Apr 5, 2018 at 2:26 AM, Matthew Garrett <mj...@google.com> wrote: > On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding <oia...@gmail.com> wrote: >> On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett <mj...@google.com> wrote: > >> > There are four cases: &g

Re: [GIT PULL] Kernel lockdown for secure boot

On Thu, Apr 5, 2018 at 2:26 AM, Matthew Garrett wrote: > On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding wrote: >> On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett wrote: > >> > There are four cases: >> > >> > Verified Boot off, lockdown off: Stat

Re: [GIT PULL] Kernel lockdown for secure boot

e boot process. Remember there is more 1 way to skin a cat just like there is more than 1 way to make a secure system. Currently being too narrow in methods for doing protected booting. Peter Dolding.

Re: [GIT PULL] Kernel lockdown for secure boot

e boot process. Remember there is more 1 way to skin a cat just like there is more than 1 way to make a secure system. Currently being too narrow in methods for doing protected booting. Peter Dolding.

Re: [GIT PULL] Kernel lockdown for secure boot

Why should the Linux kernel contain code to work around defective design of UEFI and limit what users not using UEFI and using UEFI can do? Peter Dolding

Re: [GIT PULL] Kernel lockdown for secure boot

x kernel contain code to work around defective design of UEFI and limit what users not using UEFI and using UEFI can do? Peter Dolding

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

at pushed back input processed is done by any genuine application as expected functionality. That is something that could be limited if there is no genuine users and close the door without having to modify existing applications that don't expect to-do that. Its really simple to get focused in on quick fix to problems without asking is the behaviour even required. Peter Dolding

Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

put processed is done by any genuine application as expected functionality. That is something that could be limited if there is no genuine users and close the door without having to modify existing applications that don't expect to-do that. Its really simple to get focused in on quick fix to problems without asking is the behaviour even required. Peter Dolding

Re: [RFC 0/3] WhiteEgret LSM module

On Thu, Jun 1, 2017 at 1:35 AM, Serge E. Hallyn <se...@hallyn.com> 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

Re: [RFC 0/3] WhiteEgret LSM module

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 a

Re: [RFC 0/3] WhiteEgret LSM module

On Thu, Jun 1, 2017 at 1:36 AM, Mehmet Kayaalp <mkaya...@linux.vnet.ibm.com> wrote: > >> On May 31, 2017, at 6:59 AM, Peter Dolding <oia...@gmail.com> wrote: >> >> Number 1 we need to split the idea of signed and whitelisted. IMA is >> signed should no

Re: [RFC 0/3] WhiteEgret LSM module

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

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

TIOSSTI pushback moved to its own CAP_SYS first is to find out if anything is in fact using it as part of genuine usage and allowing anyone caught out to work around it.I am sorry this is me most likely using X11 logic break it and see if anyone yells. If no one complains disappear the feature completely then this closes this form of exploit for good. Peter Dolding

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

n CAP_SYS first is to find out if anything is in fact using it as part of genuine usage and allowing anyone caught out to work around it.I am sorry this is me most likely using X11 logic break it and see if anyone yells. If no one complains disappear the feature completely then this closes this form of exploit for good. Peter Dolding

Re: [RFC 0/3] WhiteEgret LSM module

r what it had on a black list.. So design need to include option to use both whitelist and blacklist with these being simple filenames and path with checksums. We need something in Linux kernel documentation covering whitelist and blacklist with them being simple. Peter Dolding.

Re: [RFC 0/3] WhiteEgret LSM module

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

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Sat, May 20, 2017 at 12:33 AM, Serge E. Hallyn <se...@hallyn.com> wrote: > On Fri, May 19, 2017 at 12:48:17PM +1000, Peter Dolding wrote: >> Using cap_sys_admin as fix is like removing car windsheld because >> vision is being blocked by a rock hitting it. > > Nonsen

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Sat, May 20, 2017 at 12:33 AM, Serge E. Hallyn wrote: > On Fri, May 19, 2017 at 12:48:17PM +1000, Peter Dolding wrote: >> Using cap_sys_admin as fix is like removing car windsheld because >> vision is being blocked by a rock hitting it. > > Nonsense. If the applicat

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

ons to allow them to be fully disabled for 99.99 percent of people using systems. That is what people are not getting CAP_SYS_ADMIN has too many users to be counted and mitigation as well. Yes we must not break userspace but we also must mitigate against userspace issues. We do need a clear rules on how to fix these security problem user-space is allowed to be broken and of course made part of the Linux kernel documentation. Altering the binary is for sure out because the person operating the system may not have that right. Placing a flag on a binary so it works I would see as acceptable as long as that flag was not grant a stack of other privileges that application would have never had before.. Peter Dolding

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

of people using systems. That is what people are not getting CAP_SYS_ADMIN has too many users to be counted and mitigation as well. Yes we must not break userspace but we also must mitigate against userspace issues. We do need a clear rules on how to fix these security problem user-space is allowed to be broken and of course made part of the Linux kernel documentation. Altering the binary is for sure out because the person operating the system may not have that right. Placing a flag on a binary so it works I would see as acceptable as long as that flag was not grant a stack of other privileges that application would have never had before.. Peter Dolding

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Wed, May 17, 2017 at 1:48 AM, Serge E. Hallyn <se...@hallyn.com> wrote: > Quoting Kees Cook (keesc...@chromium.org): >> On Tue, May 16, 2017 at 5:22 AM, Matt Brown <m...@nmatt.com> wrote: >> > On 05/16/2017 05:01 AM, Peter Dolding wrote: >> >>>

Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Wed, May 17, 2017 at 1:48 AM, Serge E. Hallyn wrote: > Quoting Kees Cook (keesc...@chromium.org): >> On Tue, May 16, 2017 at 5:22 AM, Matt Brown wrote: >> > On 05/16/2017 05:01 AM, Peter Dolding wrote: >> >>> >> >>> >> >>> I coul

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Wed, May 17, 2017 at 12:28 AM, Kees Cook <keesc...@chromium.org> wrote: > On Tue, May 16, 2017 at 5:22 AM, Matt Brown <m...@nmatt.com> wrote: >> On 05/16/2017 05:01 AM, Peter Dolding wrote: >>>> >>>> >>>> I could see a case being make

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Wed, May 17, 2017 at 12:28 AM, Kees Cook wrote: > On Tue, May 16, 2017 at 5:22 AM, Matt Brown wrote: >> On 05/16/2017 05:01 AM, Peter Dolding wrote: >>>> >>>> >>>> I could see a case being make for CAP_SYS_TTY_CONFIG. However I still >>>&

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> > I could see a case being make for CAP_SYS_TTY_CONFIG. However I still > choose to do with CAP_SYS_ADMIN because it is already in use in the > TIOCSTI ioctl. > Matt Brown don't give me existing behaviour.CAP_SYS_ADMIN is overload. The documentation tells you that you are not to expand it

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

> > I could see a case being make for CAP_SYS_TTY_CONFIG. However I still > choose to do with CAP_SYS_ADMIN because it is already in use in the > TIOCSTI ioctl. > Matt Brown don't give me existing behaviour.CAP_SYS_ADMIN is overload. The documentation tells you that you are not to expand it

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, May 16, 2017 at 6:57 AM, Alan Cox wrote: > O> I'm not implying that my patch is supposed to provide safety for >> "hundreds of other" issues. I'm looking to provide a way to lock down a >> single TTY ioctl that has caused real security issues to arise. For > >

Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Tue, May 16, 2017 at 6:57 AM, Alan Cox wrote: > O> I'm not implying that my patch is supposed to provide safety for >> "hundreds of other" issues. I'm looking to provide a way to lock down a >> single TTY ioctl that has caused real security issues to arise. For > > In other words you are not

Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

On Nov 18, 2007 5:22 AM, Casey Schaufler <[EMAIL PROTECTED]> wrote: > > > --- Peter Dolding <[EMAIL PROTECTED]> wrote: > > > On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote: > > > Peter Dolding wrote: > > > >>> What

Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

On Nov 18, 2007 5:22 AM, Casey Schaufler [EMAIL PROTECTED] wrote: --- Peter Dolding [EMAIL PROTECTED] wrote: On Nov 17, 2007 11:08 AM, Crispin Cowan [EMAIL PROTECTED] wrote: Peter Dolding wrote: What is left unspecified here is 'how' a child 'with its own profile' is confined

Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

On Nov 17, 2007 11:08 AM, Crispin Cowan <[EMAIL PROTECTED]> wrote: > Peter Dolding wrote: > >>> What is left unspecified here is 'how' a child 'with its own profile' is > >>> confined here. Are it is confined to just its own profile, it may that > >>> t

Re: More LSM vs. Containers (having nothing at all to do with the AppArmor Security Goal)

On Nov 17, 2007 11:08 AM, Crispin Cowan [EMAIL PROTECTED] wrote: Peter Dolding wrote: What is left unspecified here is 'how' a child 'with its own profile' is confined here. Are it is confined to just its own profile, it may that the complicit process communication may need to be wider

Re: [Apparmor-dev] Re: AppArmor Security Goal

> > What is left unspecified here is 'how' a child 'with its own profile' is > > confined here. Are it is confined to just its own profile, it may that > > the "complicit process" communication may need to be wider specified to > > include this. Sorry have to bring this up. cgroups why not?

Re: [Apparmor-dev] Re: AppArmor Security Goal

What is left unspecified here is 'how' a child 'with its own profile' is confined here. Are it is confined to just its own profile, it may that the complicit process communication may need to be wider specified to include this. Sorry have to bring this up. cgroups why not? Assign

Re: Defense in depth: LSM *modules*, not a static interface

ht. There are also missing engine parts. Netlabels is only one part. Basically Capabilities flags as the hub. With sections like Netlabels and other security processing engines forking off it. Sections like Netlabels only need settings if Capabilities allows anything in the first place. This a

Re: Defense in depth: LSM *modules*, not a static interface

t least we don't need to debate about if the engine should be permissive or restrictive. Since the engine already exists. Permissive it is. Fighting with existing design is wasting time. Peter Dolding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in t

Re: Defense in depth: LSM *modules*, not a static interface

don't need to debate about if the engine should be permissive or restrictive. Since the engine already exists. Permissive it is. Fighting with existing design is wasting time. Peter Dolding - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL

Re: Defense in depth: LSM *modules*, not a static interface

security processing engines forking off it. Sections like Netlabels only need settings if Capabilities allows anything in the first place. This allows special engines for sections. Yet not having to allocate the memory when you don't need it. Peter Dolding - To unsubscribe from this list: send

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

On 11/1/07, David Newall <[EMAIL PROTECTED]> wrote: > Jan Engelhardt wrote: > > On Nov 1 2007 12:51, Peter Dolding wrote: > > > >> This is above me doing code. No matter how many fixes I do to the > >> core that will not fix dysfunction in the LSM s

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

On 11/1/07, David Newall [EMAIL PROTECTED] wrote: Jan Engelhardt wrote: On Nov 1 2007 12:51, Peter Dolding wrote: This is above me doing code. No matter how many fixes I do to the core that will not fix dysfunction in the LSM section. Strict policies on fixing the main security model

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

On 11/1/07, Casey Schaufler <[EMAIL PROTECTED]> wrote: > > --- Peter Dolding <[EMAIL PROTECTED]> wrote: > > > > Improvements to the single security framework are getting over looked. > > Please post proposed patches. > > > I would have persona

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

making a bigger and bigger mess. Peter Dolding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

On 10/31/07, Crispin Cowan <[EMAIL PROTECTED]> wrote: > Peter Dolding wrote: > > Lets end the bitrot. Start having bits go into the main OS security > > features where they should be. > > > Linus categorically rejected this idea, several times, very clearly. >

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

On 10/31/07, Crispin Cowan [EMAIL PROTECTED] wrote: Peter Dolding wrote: Lets end the bitrot. Start having bits go into the main OS security features where they should be. Linus categorically rejected this idea, several times, very clearly. He did so because the security community

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

a bigger and bigger mess. Peter Dolding - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

On 11/1/07, Casey Schaufler [EMAIL PROTECTED] wrote: --- Peter Dolding [EMAIL PROTECTED] wrote: Improvements to the single security framework are getting over looked. Please post proposed patches. I would have personally though selinux would have done Posix file capabilities

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

On 10/31/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > On Wed, 31 Oct 2007, Peter Dolding wrote: > > > MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are > > applied over using Selinux rules. This is just the way it is stacking LSM's >

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

effectively. So in my eyes it is a pure Posix extension not a LSM. Peter Dolding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FA

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

effectively. So in my eyes it is a pure Posix extension not a LSM. Peter Dolding - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

On 10/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Wed, 31 Oct 2007, Peter Dolding wrote: MultiAdmin loaded before Selinux breaks Selinux since Multi Admin rules are applied over using Selinux rules. This is just the way it is stacking LSM's is Just not healthy you always risk

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

a LSM at all. Or should it be a standard feature what LSM can over rule? Lot of things are being pushed as LSM's when they should be pushed as expanded default features outside LSM. Peter Dolding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the bod

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

part of the requirement to help other LSM's be better even if theirs ends up losing. Only if you are building a Empire does it matter who wins or loses the long term of LSM's. Only thing that truly matter is that we get the best long term. Peter Dolding - To unsubscribe from this list: s

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

if you are building a Empire does it matter who wins or loses the long term of LSM's. Only thing that truly matter is that we get the best long term. Peter Dolding - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

are being pushed as LSM's when they should be pushed as expanded default features outside LSM. Peter Dolding - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

of the problem LSM maintainers are not at the front lines is all I can guess. Because they don't seam to know what is really needed. Peter Dolding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at h

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

are not at the front lines is all I can guess. Because they don't seam to know what is really needed. Peter Dolding - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

applications normal profile of access is breached. It starts way before that. Peter Dolding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please re

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

applications normal profile of access is breached. It starts way before that. Peter Dolding - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

all mighty but it should not alter achievable security. If its altering achievable security main kernel is missing features and someone needs to slice and dice that LSM. Peter Dolding - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message

Re: Linux Security *Module* Framework (Was: LSM conversion to static interface)

all mighty but it should not alter achievable security. If its altering achievable security main kernel is missing features and someone needs to slice and dice that LSM. Peter Dolding - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL