I followed the start of this thread when it was about security mailing
lists and bug-disclosure rules, and then lost interest.
I just looked in again, and I seem to be seeing discussion of merging
grsecurity pathes into mainline. I haven't yet found an message
where this is proposed explicitly, s
On Mer, 2005-01-26 at 19:15, Olaf Hering wrote:
> And, did that nice interface help at all? No, it did not.
> Noone made seqfile mandatory in 2.6.
> Now we have a few nice big patches to carry around because every driver
> author had its own proc implementation. Well done...
seqfile has helped imm
On Thu, 27 Jan 2005, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Davidsen wrote:
On Thu, 27 Jan 2005, Zan Lynx wrote:
On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
On Wed, 26 Jan 2005, Jesse Pollar
Zan Lynx <[EMAIL PROTECTED]> writes:
> In the reality I'm familiar with, the defense contractor's secure
> projects building had one entrance, guarded by security guards who were
> not cheap $10/hr guys, with strict instructions. No computers or
> computer media were allowed to leave the building
On Thu, 27 Jan 2005, Zan Lynx wrote:
> On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
> > On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
> > > On Wed, 26 Jan 2005, Jesse Pollard wrote:
> > > > On Tuesday 25 January 2005 15:05, linux-os wrote:
> > > > > This isn't relevant at all
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Davidsen wrote:
> On Thu, 27 Jan 2005, Zan Lynx wrote:
>
>
>>On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
>>
>>>On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
>>>
On Wed, 26 Jan 2005, Jesse Pollard wrote:
>On
On Thursday 27 January 2005 11:18, Zan Lynx wrote:
> On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
>
> >
> > > > Unfortunately, there will ALWAYS be a path, either direct, or
> > > > indirect between the secure net and the internet.
> > >
> > > Other than letting people use secure compute
On Thu, 2005-01-27 at 10:37 -0600, Jesse Pollard wrote:
> On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
> > On Wed, 26 Jan 2005, Jesse Pollard wrote:
> > > On Tuesday 25 January 2005 15:05, linux-os wrote:
> > > > This isn't relevant at all. The Navy doesn't have any secure
> > > > syste
On Wednesday 26 January 2005 13:56, Bill Davidsen wrote:
> On Wed, 26 Jan 2005, Jesse Pollard wrote:
> > On Tuesday 25 January 2005 15:05, linux-os wrote:
> > > This isn't relevant at all. The Navy doesn't have any secure
> > > systems connected to a network to which any hackers could connect.
> >
On Wed, Jan 26, Linus Torvalds wrote:
> The biggest part of that is having nice interfaces. If you have good
> interfaces, bugs are less likely to be problematic. For example, the
> "seq_file" interfaces for /proc were written to clean up a lot of common
> mistakes, so that the actual low-leve
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[]
Did any of you actually READ the link I put? How the heck did we get
the navy into this?
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-BEGIN PGP SIGNATURE-
Ver
On Wed, 26 Jan 2005, Olaf Hering wrote:
>
> And, did that nice interface help at all? No, it did not.
> Noone made seqfile mandatory in 2.6.
Sure it helped. We didn't make it mandatory, but new stuff ends up being
written with it, and old stuff _does_ end up being converted to it.
> Now we ha
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sytse Wielinga wrote:
> On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
>
>>That being said, you should also consider (unless somebody forgot to
>>tell me something) that it takes two source trees to make a split-out
>>patch. Th
On Wed, Jan 26, Linus Torvalds wrote:
>
>
> On Wed, 26 Jan 2005, Olaf Hering wrote:
> >
> > And, did that nice interface help at all? No, it did not.
> > Noone made seqfile mandatory in 2.6.
>
> Sure it helped. We didn't make it mandatory, but new stuff ends up being
> written with it, and o
On Wed, Jan 26, 2005 at 02:31:00PM -0500, John Richard Moser wrote:
> Sytse Wielinga wrote:
> > On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
> >[...]
> >>true. Very very true.
> >>
> >>With things like Gr, there's like a million features. Normally the
> >>first step I take i
On Wed, 26 Jan 2005, Jesse Pollard wrote:
> On Tuesday 25 January 2005 15:05, linux-os wrote:
> > This isn't relevant at all. The Navy doesn't have any secure
> > systems connected to a network to which any hackers could connect.
> > The TDRS communications satellites provide secure channels
> >
On Wed, Jan 26, 2005 at 03:39:08PM -0500, John Richard Moser wrote:
> > I'm sorry about the rant. Besides, your comment ('Wasn't talking about
> > bugfixes') makes some sense, too. You were actually talking about two
> > patches
> > though, which close two closely related holes. Linus was talking
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sytse Wielinga wrote:
[...]
>>If you people ever bothered to read what I say, you wouldn't continually
>>say stupid shit like You get milk from cows wtf idiot
>>chocolate milk doens't come from chocolate cows
>
>
> I'm sorry about the rant. Besi
On Wed, 26 Jan 2005 14:31:00 EST, John Richard Moser said:
> [*] Grsecurity
> Security Level (Custom) --->
> Address Space Protection --->
> Role Based Access Control Options --->
> Filesystem Protections --->
> Kernel Auditing --->
> Executable Protections --->
> Network Prote
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
> On Wed, 26 Jan 2005 14:31:00 EST, John Richard Moser said:
>
>
>>[*] Grsecurity
>> Security Level (Custom) --->
>> Address Space Protection --->
>> Role Based Access Control Options --->
>> Filesystem Protections
On Wed, 26 Jan 2005, Olaf Hering wrote:
> >
> > Details, please?
>
> You did it this way:
> http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]
Oh, that's a separate issue. We want to have multiple levels of security.
We not only try to make sure that there are easy interfaces (but yeah,
On Wed, 26 Jan 2005, Jesse Pollard wrote:
>
> And covering the possible unknown errors is a good way to add protection.
I heartily agree. The more we can do to make the inevitable bugs be less
likely to be security problems, the better off we are. Most of that ends
up being design - trying to
On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
> That being said, you should also consider (unless somebody forgot to
> tell me something) that it takes two source trees to make a split-out
> patch. The author also has to chew down everything but the feature he
> wants to spli
On Tuesday 25 January 2005 15:05, linux-os wrote:
> On Tue, 25 Jan 2005, John Richard Moser wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
[snip]
> > In this context, it doesn't make sense to deploy a protection A or B
> > without the companion protection, which is what I meant.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Davidsen wrote:
> On Tue, 25 Jan 2005, John Richard Moser wrote:
>
>
>
>>Thus, by having fewer exploits available, fewer successful attacks
>>should happen due to the laws of probability. So the goal becomes to
>>fix as many bugs as possible
On Tue, 25 Jan 2005, John Richard Moser wrote:
> Thus, by having fewer exploits available, fewer successful attacks
> should happen due to the laws of probability. So the goal becomes to
> fix as many bugs as possible, but also to mitigate the ones we don't
> know about. To truly mitigate any s
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
linux-os wrote:
> On Tue, 25 Jan 2005, John Richard Moser wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>>
>>
>> Dmitry Torokhov wrote:
>>
>>> On Tue, 25 Jan 2005 13:37:10 -0500, John Richard Moser
>>> <[EMAIL PROTECTED]> wrote:
>>
On Tue, Jan 25, 2005 at 03:03:04PM -0500, John Richard Moser wrote:
> > and combining them has _zero_ advantages (whatever bug the combined patch
> > fix _will_ be fixed by the series of individual patches too - even if the
> > splitting was buggy in some respect, you are pretty much guaranteed of
On Tue, 25 Jan 2005, John Richard Moser wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dmitry Torokhov wrote:
On Tue, 25 Jan 2005 13:37:10 -0500, John Richard Moser
<[EMAIL PROTECTED]> wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
On Tue, 25 Jan 2005, John Richar
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
> On Tue, 25 Jan 2005 14:56:13 EST, John Richard Moser said:
>
>
>>This puts pressure on the attacker; he has to find a bug, write an
>>exploit, and find an opportunity to use it before a patch is written and
>>applied to f
On Tue, 25 Jan 2005 14:56:13 EST, John Richard Moser said:
> This puts pressure on the attacker; he has to find a bug, write an
> exploit, and find an opportunity to use it before a patch is written and
> applied to fix the exploit. If say 80% of exploits are suddenly
> non-exploitable, then he's
On Tue, Jan 25, 2005 at 03:29:44PM -0500, John Richard Moser wrote:
> This still doesn't give me any way to take a big patch and make little
> patches without hours of work and (N+2) kernel trees for N patches
Any path to getting a big complicated patch reviewed and into the kernel
is going to inv
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
J. Bruce Fields wrote:
> On Tue, Jan 25, 2005 at 02:56:13PM -0500, John Richard Moser wrote:
>
>>In this context, it doesn't make sense to deploy a protection A or B
>>without the companion protection, which is what I meant.
>
>
> But breaking up
On Tue, Jan 25, 2005 at 02:56:13PM -0500, John Richard Moser wrote:
> In this context, it doesn't make sense to deploy a protection A or B
> without the companion protection, which is what I meant.
But breaking up the introduction of new code into logical steps is still
helpful for people trying t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
>
> On Tue, 25 Jan 2005, John Richard Moser wrote:
>
>>>Sure there is. There's the gain that if you lock the front door but not
>>>the back door, somebody who goes door-to-door, opportunistically knocking
>>>on them and test
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dmitry Torokhov wrote:
> On Tue, 25 Jan 2005 13:37:10 -0500, John Richard Moser
> <[EMAIL PROTECTED]> wrote:
>
>>-BEGIN PGP SIGNED MESSAGE-
>>Hash: SHA1
>>
>>
>>Linus Torvalds wrote:
>>
>>>On Tue, 25 Jan 2005, John Richard Moser wrote:
>>>
>
On Tue, 25 Jan 2005, John Richard Moser wrote:
> >
> > Sure there is. There's the gain that if you lock the front door but not
> > the back door, somebody who goes door-to-door, opportunistically knocking
> > on them and testing them, _will_ be discouraged by locking the front door.
>
> In th
On Tue, 25 Jan 2005 13:37:10 -0500, John Richard Moser
<[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Linus Torvalds wrote:
> >
> > On Tue, 25 Jan 2005, John Richard Moser wrote:
> >
> >>It's kind of like locking your front door, or your back door. If one is
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Linus Torvalds wrote:
>
> On Tue, 25 Jan 2005, John Richard Moser wrote:
>
>>It's kind of like locking your front door, or your back door. If one is
>>locked and the other other is still wide open, then you might as well
>>not even have doors. If
On Tue, 25 Jan 2005, John Richard Moser wrote:
>
> It's kind of like locking your front door, or your back door. If one is
> locked and the other other is still wide open, then you might as well
> not even have doors. If you lock both, then you (finally) create a
> problem for an intruder.
>
On Tue, 25 Jan 2005, Bill Davidsen wrote:
>
> No,perhaps it isn't clear. If A changes the way a lock is used (for
> example), then all the places which were using the lock the old way have
> to use it the new way, or lockups or similar bad behaviour occur.
Sure. Some patches are like that, bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bill Davidsen wrote:
> Linus Torvalds wrote:
>
>>
>> On Tue, 25 Jan 2005, Bill Davidsen wrote:
>>
>>> Unfortunately if A depends on B to work at all, you have to put A and
>>> B in as a package.
>>
>>
>>
>> No. That's totally bogus. You can put in B
Linus Torvalds wrote:
On Tue, 25 Jan 2005, Bill Davidsen wrote:
Unfortunately if A depends on B to work at all, you have to put A and B
in as a package.
No. That's totally bogus. You can put in B on its own. You do not have to
make A+B be one patch.
No,perhaps it isn't clear. If A changes the wa
On Tue, 25 Jan 2005, Bill Davidsen wrote:
>
> Unfortunately if A depends on B to work at all, you have to put A and B
> in as a package.
No. That's totally bogus. You can put in B on its own. You do not have to
make A+B be one patch.
> There is no really good way (AFAIK) to submit a bunch of
[EMAIL PROTECTED] wrote:
On Wed, 19 Jan 2005 13:50:23 EST, John Richard Moser said:
Arjan van de Ven wrote:
Split-out portions of PaX (and of ES) don't make sense.
they do. Somewhat.
They do to "break all existing exploits" until someone takes 5 minutes
to make a slight alteration. Only the re
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Hellwig wrote:
> On Thu, Jan 20, 2005 at 01:16:33PM -0500, John Richard Moser wrote:
>
>>Granted, you're somewhat more diverse than I pointed out; but I don't
>>keep up on what you're doing. The point was more that you're not a
>>major se
On Thu, Jan 20, 2005 at 01:16:33PM -0500, John Richard Moser wrote:
> Granted, you're somewhat more diverse than I pointed out; but I don't
> keep up on what you're doing. The point was more that you're not a
> major security figure and/or haven't donated your life to security and
> forsaken all l
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
> On Thu, 2005-01-20 at 13:16 -0500, John Richard Moser wrote:
>
>>Even when the tagging is all automatic, to really deploy a competantly
>>formed system you have to review the results of the automated tagging.
>>It's a bit e
On Thu, 20 Jan 2005 13:16:33 EST, John Richard Moser said:
> > 1) the halving of the per-process VM space from 3GB to 1.5GB.
> Which has *never* caused a problem in anything I've ever used, and can
> be disabled on a per-process basis.
Just because something has never caused *you* a problem does
On Thu, 2005-01-20 at 13:16 -0500, John Richard Moser wrote:
> Even when the tagging is all automatic, to really deploy a competantly
> formed system you have to review the results of the automated tagging.
> It's a bit easier in most cases to automate-and-review, but it still has
> to be done. I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingo Molnar wrote:
> * John Richard Moser <[EMAIL PROTECTED]> wrote:
>
>
>>I respect you as a kernel developer as long as you're doing preemption
>>and schedulers; [...]
>
>
> actually, 'preemption and schedulers' ignores 80% of my contributions
* John Richard Moser <[EMAIL PROTECTED]> wrote:
> I respect you as a kernel developer as long as you're doing preemption
> and schedulers; [...]
actually, 'preemption and schedulers' ignores 80% of my contributions to
Linux so i'm not sure what to make of your comment :-| Here's a list of
bigger
* John Richard Moser <[EMAIL PROTECTED]> wrote:
> > Exec Shield does that too but only if your CPU has hardware assist for
> > NX (which all current AMD and most current intel cpus do).
>
> Uh, ok. You've read the code right? *would rather hear from Ingo*
FYI, Arjan is one of the exec-shield
* John Richard Moser <[EMAIL PROTECTED]> wrote:
> On a final note, isn't PaX the only technology trying to apply NX
> protections to kernel space? [...]
NX protection for kernel-space overflows on x86 has been part of the
mainline kernel as of June 2004 (released in 2.6.8), on CPUs that
support
On Wed, 19 Jan 2005 16:03:06 EST, John Richard Moser said:
(New Subject: line to split this thread out...)
> > Even better would be a 30-40 patch train for PaX, a 10-15 patch train
> > for the other randomization stuff in grsecurity (pid, port number, all
> > the rest of those), a 50-60 patch tra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
> On Wed, 19 Jan 2005 15:12:05 EST, John Richard Moser said:
>
>
>>>And why were they merged? Because they showed up in 4-8K chunks.
>
>
>>so you want 90-200 split out patches for GrSecurity?
>
>
> Even better would be
[trimming of cc list since this has nothing to see with the thread]
El Wed, 19 Jan 2005 15:12:05 -0500 John Richard Moser <[EMAIL PROTECTED]>
escribió:
> so you want 90-200 split out patches for GrSecurity?
Documentation/SubmittingPatches.txt is all you need to read.
There has been a lot of go
On Wed, 19 Jan 2005 20:53:51 +0100, Arjan van de Ven said:
> > Now look at http://www.kernel.org/pub/linux/kernel/people/arjan/execshield/
.
> > 4 separate hunks, the biggest is under 7K. Other chunks of similar size
> > for non-exec stack and NX support are already merged.
> >
> > And why were
On Wed, 19 Jan 2005 15:12:05 EST, John Richard Moser said:
> > And why were they merged? Because they showed up in 4-8K chunks.
> so you want 90-200 split out patches for GrSecurity?
Even better would be a 30-40 patch train for PaX, a 10-15 patch train
for the other randomization stuff in grsec
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[EMAIL PROTECTED] wrote:
> On Wed, 19 Jan 2005 13:50:23 EST, John Richard Moser said:
>
>>Arjan van de Ven wrote:
>>
Split-out portions of PaX (and of ES) don't make sense.
>>>
>>>they do. Somewhat.
>
>
>>They do to "break all existing expl
Linus Torvalds wrote:
On Wed, 12 Jan 2005, Dave Jones wrote:
For us thankfully, exec-shield has trapped quite a few remotely
exploitable holes, preventing the above.
One thing worth considering, but may be abit _too_ draconian, is a
capability that says "can execute ELF binaries that you can write
> 700K. In one patch. If PAX is available for 2.6.10 by itself, it certainly
> hasn't been posted to http://pax.grsecurity.net - that's still showing a 2.6.7
> patch. But even there, that's a single monolithic 280K patch. That's never
> going to get merged, simply because *nobody* can review a s
> >
> > Exec Shield does that too but only if your CPU has hardware assist for
> > NX (which all current AMD and most current intel cpus do).
> >
>
> Uh, ok. You've read the code right? *would rather hear from Ingo*
I co-developed a bunch of it together with Ingo in fact, and did lots
and lo
On Wed, 19 Jan 2005 13:50:23 EST, John Richard Moser said:
> Arjan van de Ven wrote:
> >>Split-out portions of PaX (and of ES) don't make sense.
> > they do. Somewhat.
> They do to "break all existing exploits" until someone takes 5 minutes
> to make a slight alteration. Only the reciprocating
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
>>I respect you as a kernel developer as long as you're doing preemption
>>and schedulers; but I honestly think PaX is the better technology, and I
>>think it's important that the best security technology be in place.
>
>
Alban Browaeys wrote:
Bill Davidsen tmr.com> writes:
With no disrespect, I don't believe you have ever been a full-time
employee system administrator for any commercial or government
organization, and I don't believe you have any experience trying to do
security when change must be reviewed by
> I respect you as a kernel developer as long as you're doing preemption
> and schedulers; but I honestly think PaX is the better technology, and I
> think it's important that the best security technology be in place.
the difference is not that big and only in tradeoffs. eg pax trades
virtual ad
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
>>ES has been actively developed since it was poorly implemented in 2003.
>> PaX has been actively developed since it was poorly implemented in
>>2000. PaX has had about 4 times longer to go from a poor
>>proof-of-concept NX
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingo Molnar wrote:
> * John Richard Moser <[EMAIL PROTECTED]> wrote:
>
>
>>Split-out portions of PaX (and of ES) don't make sense. [...]
>
>
> which shows that you dont know the exec-shield patch at all, nor those
> split-out portions. At which p
> ES has been actively developed since it was poorly implemented in 2003.
> PaX has been actively developed since it was poorly implemented in
> 2000. PaX has had about 4 times longer to go from a poor
> proof-of-concept NX emulation patch based on the plex86 announcement to
> a full featured sec
* John Richard Moser <[EMAIL PROTECTED]> wrote:
> Split-out portions of PaX (and of ES) don't make sense. [...]
which shows that you dont know the exec-shield patch at all, nor those
split-out portions. At which point it becomes pretty pointless to
discuss any technical details, dont you think?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ingo Molnar wrote:
> * John Richard Moser <[EMAIL PROTECTED]> wrote:
>
>
>>>There was a kernel-based randomization patch floating around at some
>>>point, though. I think it's part of PaX. That's the one I hated.
>>
>>PaX and Exec Shield both hav
Hi!
> > For us thankfully, exec-shield has trapped quite a few remotely
> > exploitable holes, preventing the above.
>
> One thing worth considering, but may be abit _too_ draconian, is a
> capability that says "can execute ELF binaries that you can write to".
>
> Without that capability set, yo
* John Richard Moser <[EMAIL PROTECTED]> wrote:
> > There was a kernel-based randomization patch floating around at some
> > point, though. I think it's part of PaX. That's the one I hated.
>
> PaX and Exec Shield both have them; personally I believe PaX is a more
> mature technology, since it
Bill Davidsen tmr.com> writes:
>
> With no disrespect, I don't believe you have ever been a full-time
> employee system administrator for any commercial or government
> organization, and I don't believe you have any experience trying to do
> security when change must be reviewed by technicall
With no disrespect, I don't believe you have ever been a full-time
employee system administrator for any commercial or government
organization, and I don't believe you have any experience trying to do
security when change must be reviewed by technically naive management to
justify cost, time, a
76 matches
Mail list logo
