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
cker has to get past.
So fairly much 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
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
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.
>
> Maybe t
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
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
reat against the 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.
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
and having that 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
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
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
back 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
o approve everything bar what it had on a black
list..
So design need to include option to use both whitelist and blacklist
with these being simple filenames and path with checksums. We need
something in Linux kernel documentation covering whitelist and
blacklist with them being simple.
Peter Dolding.
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 application h
ed functions 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
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
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
>>>&
>
> 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
a
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 ac
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
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
> > 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? Assi
cation paper weight. 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
f
be basically security module neutral.
Yes at 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
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 secti
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
king 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/
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.
>
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'
wn root powers and handing them out more 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.or
should RaceGuard be 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
;t
seam to think its 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
rt 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 major
loss does not start only when 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/ma
o run security tight. The big
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&
35 matches
Mail list logo
