Re: thoughts on kernel security issues
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, so if I am inferring incorrectly, I apologize. (And you can ignore the rest of this missive.) However, I did look carefully at an earlier patch that claimed to be a Linux port of some OpenBSD networking randomization code, ostensibly to make packet-guessing attacks more difficult. http://marc.theaimsgroup.com/?l=linux-kernel&m=110693283511865 It was further claimed that this code came via grsecurity. I did verify that the code looked a lot like pieces of OpenBSD, but didn't look at grsecurity at all. However, I did look in some detail at the code itself. http://marc.theaimsgroup.com/?l=linux-netdev&m=110736479712671 What I concluded was that it was broken beyond belief, and the effect on the networking code varied from (due to putting the IP ID generation code in the wrong place) wasting a lot of time randomizing a number that could be a constant zero if not for working around a bug in Microsoft's PPP stack, to (RPC XID generation) severe protocol violation. Not to mention race conditions out the wazoo due to porting single-threaded code. After careful review, I couldn't find a single redeeming feature, or even a good idea that was merely implemented badly. See the posting for details and more colorful criticism. Now, as I said, I have *not* gone to the trouble of seeing if this patch really did come from grsecurity, or if it was horribly damaged in the process of splitting it out. So I may be unfairly blaming grsecurity, but I didn't feel like seeking out more horrible code to torture my sanity with. My personal, judgemental opinion was that if that was typical of grsecurity, it's a festering pile of pus that I'm not going to let anywhere near my kernel, thank you very much. But to the extent that this excerpt constitutes reasonable grounds for suspicion, I would like to recommend a particularly careful review of any grsecurity patches. In addition to Linus' dislike of monolithic patches. Just my $0.02. - 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: thoughts on kernel security issues
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 immensely from what I can see. And gradually it takes over the kernel because each time someone has a broken proc driver it is easier to rewrite it in seq_file than fix it any other way. All good API's work that way, and they really do work. You only have to look at things like the statistics for Gnome application string caused security errors versus those for generic C apps to see the huge effect stuff like g_string classes have had on reliability. We need *more* API's like this - we are lacking some nice helpers for simple block/char devices and also lacking a "call under lock" construct which avoids forgetting to drop locks for example. Alan - 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: thoughts on kernel security issues
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 Pollard wrote: On Tuesday 25 January 2005 15:05, linux-os wrote: This isn't relavent [Stuff about the navy][...] The Navy [...] [...]Physical network topology[...] [...]sneakernet[...] [...]path[...] [...]internet[...] [...]hahaha[...] [...]NSA[...] [...]security clearance[...] I'll ask again How the [EMAIL PROTECTED] did the navy get involved in this discussion? That's where the love-you virus was (supposed to have been) introduced into a secure system. It's probably, with I would guess a probable 89-90 percent probability, some BS. You spelled [EMAIL PROTECTED] wrong. The 'u' is ahead of the 'c'. You dyslexic or something? - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - 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: thoughts on kernel security issues
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 except with written > authorization of a corporate officer. Wow, nice. How do they check for, say, Compact Flashes or, for example, even smaller XD-picture cards? -- Krzysztof Halasa - 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: thoughts on kernel security issues
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. 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
> > > > > that are disassembled on-board. Some ATM-slot, after decryption
> > > > > is fed to a LAN so the sailors can have an Internet connection
> > > > > for their lap-tops. The data took the same paths, but it's
> > > > > completely independent and can't get mixed up no matter how
> > > > > hard a hacker tries.
> > > >
> > > > Obviously you didn't hear about the secure network being hit by the "I
> > > > love you" virus.
> > > >
> > > > The Navy doesn't INTEND to have any secure systems connected to a
> > > > network
> > > > to which any hackers could connect.
> > >
> > > What's hard about that? Matter of physical network topology, absolutely no
> > > physical connection, no machines with a 2nd NIC, no access to/from I'net.
> > > Yes, it's a PITA, add logging to a physical printer which can't be erased
> > > if you want to make your CSO happy (corporate security officer).
> >
> > And you are ASSUMING the connection was authorized. I can assure you that
> > there are about 200 (more or less) connections from the secure net to the
> > internet expressly for the purpose of transferring data from the internet
> > to the secure net for analysis. And not ALL of these connections are
> > authorized. Some are done via sneakernet, others by running a cable ("I need
> > the data NOW... I'll just disconnect afterward..."), and are not visible
> > for very long. Other connections are by picking up a system and carrying it
> > from one connection to another (a version of sneakernet, though here it
> > sometimes needs a hand cart).
> >
> > > > Unfortunately, there will ALWAYS be a path, either direct, or indirect
> > > > between the secure net and the internet.
> > >
> > > Other than letting people use secure computers after they have seen the
> > > Internet, a good setup has no indirect paths.
> >
> > Ha. Hahaha...
> >
> > Reality bites.
>
> 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 except with written
> authorization of a corporate officer. The building was shielded against
> Tempest attacks and verified by the NSA. Any computer hardware or media
> brought into the building for the project was physically destroyed at
> the end.
That sounds familiar... Doing any of the things mentioned above would (if
detected) result in firing on the spot, loss of security clearance, and a
stunningly bad reference if anyone did an employment check.
Not to mention possible civil or criminal prosecution in some cases.
--
bill davidsen <[EMAIL PROTECTED]>
CTO, TMR Associates, Inc
Doing interesting things with little computers since 1979.
signature.asc
Description: This is a digitally signed message part
Re: thoughts on kernel security issues
-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 Tuesday 25 January 2005 15:05, linux-os wrote: > >>This isn't relavent [Stuff about the navy][...] > >The Navy [...] [...]Physical network topology[...] >>> >>>[...]sneakernet[...] >>> >>> >[...]path[...] [...]internet[...] >>> >>>[...]hahaha[...] >> >>[...]NSA[...] > > > [...]security clearance[...] > I'll ask again How the [EMAIL PROTECTED] did the navy get involved in this discussion? - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB+XrshDd4aOud5P8RAlYQAKCIoi9N6fsNcmjHrT+S5nVptw8sdACfQuZ6 cpAXu20BIaitjRvuqwJq/K4= =zbim -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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 computers after they have seen the > > > Internet, a good setup has no indirect paths. > > > > Ha. Hahaha... > > > > Reality bites. > > 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 except with written > authorization of a corporate officer. The building was shielded against > Tempest attacks and verified by the NSA. Any computer hardware or media > brought into the building for the project was physically destroyed at > the end. > And you are assuming that everybody follows the rules. when a PHB, whether military or not (and not contractor) comes in and says "... I don't care what it takes... get that data over there NOW..." guess what - it gets done. Even if it is "less secure" in the process. Oh - and about that "physically destroyed" - that used to be true. Until it was pointed out to them that destruction of 300TB of data media would cost them about 2 Million. Suddenly, erasing became popular. And sufficient. Then it was reused in a non-secure facility, operated by the same CO. > Secure nets _are_ possible. Yes they are. But they are NOT reliable. Don't ever assume a "secure" network really is. All it means is: "as secure as we can manage" - 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: thoughts on kernel security issues
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
> > > > systems connected to a network to which any hackers could connect.
> > > > The TDRS communications satellites provide secure channels
> > > > that are disassembled on-board. Some ATM-slot, after decryption
> > > > is fed to a LAN so the sailors can have an Internet connection
> > > > for their lap-tops. The data took the same paths, but it's
> > > > completely independent and can't get mixed up no matter how
> > > > hard a hacker tries.
> > >
> > > Obviously you didn't hear about the secure network being hit by the "I
> > > love you" virus.
> > >
> > > The Navy doesn't INTEND to have any secure systems connected to a network
> > > to which any hackers could connect.
> >
> > What's hard about that? Matter of physical network topology, absolutely no
> > physical connection, no machines with a 2nd NIC, no access to/from I'net.
> > Yes, it's a PITA, add logging to a physical printer which can't be erased
> > if you want to make your CSO happy (corporate security officer).
>
> And you are ASSUMING the connection was authorized. I can assure you that
> there are about 200 (more or less) connections from the secure net to the
> internet expressly for the purpose of transferring data from the internet
> to the secure net for analysis. And not ALL of these connections are
> authorized. Some are done via sneakernet, others by running a cable ("I need
> the data NOW... I'll just disconnect afterward..."), and are not visible
> for very long. Other connections are by picking up a system and carrying it
> from one connection to another (a version of sneakernet, though here it
> sometimes needs a hand cart).
>
> > > Unfortunately, there will ALWAYS be a path, either direct, or indirect
> > > between the secure net and the internet.
> >
> > Other than letting people use secure computers after they have seen the
> > Internet, a good setup has no indirect paths.
>
> Ha. Hahaha...
>
> Reality bites.
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 except with written
authorization of a corporate officer. The building was shielded against
Tempest attacks and verified by the NSA. Any computer hardware or media
brought into the building for the project was physically destroyed at
the end.
Secure nets _are_ possible.
--
Zan Lynx <[EMAIL PROTECTED]>
signature.asc
Description: This is a digitally signed message part
Re: thoughts on kernel security issues
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.
> > > The TDRS communications satellites provide secure channels
> > > that are disassembled on-board. Some ATM-slot, after decryption
> > > is fed to a LAN so the sailors can have an Internet connection
> > > for their lap-tops. The data took the same paths, but it's
> > > completely independent and can't get mixed up no matter how
> > > hard a hacker tries.
> >
> > Obviously you didn't hear about the secure network being hit by the "I
> > love you" virus.
> >
> > The Navy doesn't INTEND to have any secure systems connected to a network
> > to which any hackers could connect.
>
> What's hard about that? Matter of physical network topology, absolutely no
> physical connection, no machines with a 2nd NIC, no access to/from I'net.
> Yes, it's a PITA, add logging to a physical printer which can't be erased
> if you want to make your CSO happy (corporate security officer).
And you are ASSUMING the connection was authorized. I can assure you that
there are about 200 (more or less) connections from the secure net to the
internet expressly for the purpose of transferring data from the internet
to the secure net for analysis. And not ALL of these connections are
authorized. Some are done via sneakernet, others by running a cable ("I need
the data NOW... I'll just disconnect afterward..."), and are not visible
for very long. Other connections are by picking up a system and carrying it
from one connection to another (a version of sneakernet, though here it
sometimes needs a hand cart).
> > Unfortunately, there will ALWAYS be a path, either direct, or indirect
> > between the secure net and the internet.
>
> Other than letting people use secure computers after they have seen the
> Internet, a good setup has no indirect paths.
Ha. Hahaha...
Reality bites.
> > The problem exists. The only to protect is to apply layers of protection.
> >
> > And covering the possible unknown errors is a good way to add protection.
-
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: thoughts on kernel security issues
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-level code would be much simpler and not > have to worry about things like buffer sizes and page boundaries. I don't > know/remember if it actually fixed any security issues, but I'm confident > it made them less likely, just by making it _easier_ to write code that > doesn't have silly bounds problems. 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... - 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: thoughts on kernel security issues
-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- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9+5+hDd4aOud5P8RAnrJAKCAGRMebZP3EX1pvqxhWInQVQgGVQCfbu2f XxZez57GG7z66bhlQTOX0M0= =fcXP -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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 have a few nice big patches to carry around because every driver > author had its own proc implementation. Well done... Details, please? Linus - 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: thoughts on kernel security issues
-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. The author also has to chew down everything but the feature he
>>wants to split out. I could probably log 10,000 man-hours splitting up
>>GrSecurity. :)
>
>
> I'd try out Andrew's patch scripts if I were you. If you're making a patch to
> the kernel, you'd best keep it in separate patches from the beginning, and
> that's exactly what those scripts are very useful for.
>
>
>>>It's also a lot easier to find the (inevitable) bugs. Either you already
>>>have a clue ("try reverting that one patch") or you can do things like
>>>binary searching. The bugs introduced a patch often have very little to do
>>>with the thing a patch fixes - exactly because the patch _fixes_
>>>something, it's been tested with that particular problem, and the new
>>>problem it introduces is usually orthogonal.
>>
>>true. Very very true.
>>
>>With things like Gr, there's like a million features. Normally the
>>first step I take is "Disable it all". If it still breaks, THEN THERE'S
>>A PROBLEM. If it works, then the binary searching begins.
>
>
> So how do you think you would do a binary search within big patches, if it
> would take you 10,000 man-hours to split up the patch? Disabling a lot of
> small patches is easy, disabling a part of a big one takes a lot more work.
>
'make menuconfig' is not a lot more work wtf
[*] Grsecurity
Security Level (Custom) --->
Address Space Protection --->
Role Based Access Control Options --->
Filesystem Protections --->
Kernel Auditing --->
Executable Protections --->
Network Protections --->
Sysctl support --->
Logging Options --->
?? Address Space Protection ??
[ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port
[ ] Disable privileged I/O
[*] Remove addresses from /proc//[maps|stat]
[*] Deter exploit bruteforcing
[*] Hide kernel symbols
Need I continue? There's some 30 or 40 more options I could show. If
you can't use your enter, left, right, up, y, n, and ? keys, you're
crippled and won't be able to patch and unpatch crap either.
>
>>>Which is why lots of small patches usually have _different_ bug behaviour
>>>than the patch they fix. To go back to the A+B fix: the bug they fix may
>>>be fixed only by the _combination_ of the patch, but the bug they cause is
>>>often an artifact of _one_ of the patches.
>>>
>>
>>Wasn't talking about bugfixes, see above.
>
>
> Oh, so you're saying that security fixes don't cause bugs? Great world you
> live
> in, then...
>
I didn't say that. I said I wasn't talking about bugfix patches. I
wasn't talking about "mremap(0,0) gives you root," I was talking about
"preventing following links under X conditions breaks nothing legitimate
but deadstops /tmp races" or "properly setting CPU protections for
PROT_EXEC stops code injection" or "ASLR stops ret2libc attacks."
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
>
>>>IOW, splitting the patches up makes them
>>> - easier to merge
>>> - easier to verify
>>> - easier to debug
>>>
>>>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
>>>this, since the bug you were trying to fix is the _one_ thing you are
>>>really testing for).
>>
>>Lots of work to split up a patch though.
>
>
> See above.
>
> Sytse
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB9+/zhDd4aOud5P8RAsZzAJ4rUryqsKc1OcfT4Nwc1m/lJtePPwCfXMWx
fEoc1nSxOfEzjJNZRDx6qYQ=
=NYJe
-END PGP SIGNATURE-
-
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: thoughts on kernel security issues
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 old stuff _does_ end up being converted to it. 2.5 was the right time to enforce it. > > Now we have a few nice big patches to carry around because every driver > > author had its own proc implementation. Well done... > > Details, please? You did it this way: http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED] - 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: thoughts on kernel security issues
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 is "Disable it all". If it still breaks, THEN THERE'S
> >>A PROBLEM. If it works, then the binary searching begins.
> >
> >
> > So how do you think you would do a binary search within big patches, if it
> > would take you 10,000 man-hours to split up the patch? Disabling a lot of
> > small patches is easy, disabling a part of a big one takes a lot more work.
>
> 'make menuconfig' is not a lot more work wtf
>
>
> [*] Grsecurity
> Security Level (Custom) --->
> Address Space Protection --->
> Role Based Access Control Options --->
> Filesystem Protections --->
> Kernel Auditing --->
> Executable Protections --->
> Network Protections --->
> Sysctl support --->
> Logging Options --->
>
> ?? Address Space Protection ??
> [ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port
> [ ] Disable privileged I/O
> [*] Remove addresses from /proc//[maps|stat]
> [*] Deter exploit bruteforcing
> [*] Hide kernel symbols
>
> Need I continue? There's some 30 or 40 more options I could show. If
> you can't use your enter, left, right, up, y, n, and ? keys, you're
> crippled and won't be able to patch and unpatch crap either.
Granted, in some patches you can disable certain features by turning off config
options. Even though it's much less convenient and you might miss out on some
parts because bugs may be introduced that aren't disabled by any option and
even if you find the option that triggers the bug, you still may have lots of
code to check because the option enables a large piece of code, and will have
to work with the entire patch instead of just a small one, in the case of a
well-written patch it's mostly very inconvenient. It still is a good habit to
split out the work you do into small parts though.
> >>>Which is why lots of small patches usually have _different_ bug behaviour
> >>>than the patch they fix. To go back to the A+B fix: the bug they fix may
> >>>be fixed only by the _combination_ of the patch, but the bug they cause is
> >>>often an artifact of _one_ of the patches.
> >>>
> >>
> >>Wasn't talking about bugfixes, see above.
> >
> >
> > Oh, so you're saying that security fixes don't cause bugs? Great world you
> > live
> > in, then...
> >
>
> I didn't say that. I said I wasn't talking about bugfix patches. I
> wasn't talking about "mremap(0,0) gives you root," I was talking about
> "preventing following links under X conditions breaks nothing legitimate
> but deadstops /tmp races" or "properly setting CPU protections for
> PROT_EXEC stops code injection" or "ASLR stops ret2libc attacks."
>
> 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. 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 about the
possible bugs caused by either one of these two patches, which may be totally
unrelated to the thing they try to fix.
Sytse
-
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: thoughts on kernel security issues
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 > > that are disassembled on-board. Some ATM-slot, after decryption > > is fed to a LAN so the sailors can have an Internet connection > > for their lap-tops. The data took the same paths, but it's > > completely independent and can't get mixed up no matter how > > hard a hacker tries. > > Obviously you didn't hear about the secure network being hit by the "I love > you" virus. > > The Navy doesn't INTEND to have any secure systems connected to a network to > which any hackers could connect. What's hard about that? Matter of physical network topology, absolutely no physical connection, no machines with a 2nd NIC, no access to/from I'net. Yes, it's a PITA, add logging to a physical printer which can't be erased if you want to make your CSO happy (corporate security officer). > > Unfortunately, there will ALWAYS be a path, either direct, or indirect between > the secure net and the internet. Other than letting people use secure computers after they have seen the Internet, a good setup has no indirect paths. > > The problem exists. The only to protect is to apply layers of protection. > > And covering the possible unknown errors is a good way to add protection. > -- bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - 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: thoughts on kernel security issues
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 about the
> > possible bugs caused by either one of these two patches, which may be
> > totally
> > unrelated to the thing they try to fix.
> Sorry, I just woke up, this thread has me under a lot of stress. I
> should go back to arguing things that have some end goal to them, rather
> than arguing simply because I have nothing better to do.
Yes.. it seems that the thread has gone in a rather pointless direction, noone
seems to know exactly what it was about anymore but everyone keeps carrying
huge emotions all over the place. Let's just forget it and move on :-)
Sytse
-
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: thoughts on kernel security issues
-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. 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 about the
> possible bugs caused by either one of these two patches, which may be totally
> unrelated to the thing they try to fix.
>
Sorry, I just woke up, this thread has me under a lot of stress. I
should go back to arguing things that have some end goal to them, rather
than arguing simply because I have nothing better to do.
> Sytse
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB9//rhDd4aOud5P8RAqJ4AKCOUHogl5iN8txWkw971x9TlJPJeQCghz4v
tBGYkU69tUQnKdZnyez0+10=
=8DIE
-END PGP SIGNATURE-
-
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: thoughts on kernel security issues
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 Protections ---> > Sysctl support ---> > Logging Options ---> > > ?? Address Space Protection ?? > [ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port > [ ] Disable privileged I/O > [*] Remove addresses from /proc//[maps|stat] > [*] Deter exploit bruteforcing > [*] Hide kernel symbols > > Need I continue? There's some 30 or 40 more options I could show. If > you can't use your enter, left, right, up, y, n, and ? keys, you're > crippled and won't be able to patch and unpatch crap either. Just because I can use my arrow keys doesn't mean I can find which part of a 250,000 line patch broke something. If it's done as 30 or 40 patches, each of which implements ONE OPTION, then it's pretty easy to play binary search to find what broke something. And don't give me "it doesn't break anything" - in the past, I've fed at least 2 bug fixes on things I found broken back to the grsecurity crew (one was a borkage in the process-ID-randomization code, another was a bad parenthesis matching breaking the intent of an 'if' in one of the filesystem protection checks (symlink or fifo or something like that). pgppLtgU3Qxtw.pgp Description: PGP signature
Re: thoughts on kernel security issues
-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 ---> >> Kernel Auditing ---> >> Executable Protections ---> >> Network Protections ---> >> Sysctl support ---> >> Logging Options ---> >> >>?? Address Space Protection ?? >> [ ] Deny writing to /dev/kmem, /dev/mem, and /dev/port >> [ ] Disable privileged I/O >> [*] Remove addresses from /proc//[maps|stat] >> [*] Deter exploit bruteforcing >> [*] Hide kernel symbols >> >>Need I continue? There's some 30 or 40 more options I could show. If >>you can't use your enter, left, right, up, y, n, and ? keys, you're >>crippled and won't be able to patch and unpatch crap either. > > > Just because I can use my arrow keys doesn't mean I can find which part of > a 250,000 line patch broke something. > I can. Read Kconfig. Find the CONFIG_* for the option. Find what that disables in the code. Get to work. > If it's done as 30 or 40 patches, each of which implements ONE OPTION, then > it's pretty easy to play binary search to find what broke something. > Yes and those patches would implement what's inside #ifdef CONFIG_*'s, so if turning an option off fixes something, it's fairly equivalent. I'll let it slide that those patches would likley make "some" changes that aren't in #ifdef blocks, making it a bit harder to track down, since those changes can also cause breakage themselves and be even tougher to track down (though maybe not, just read the patch for non-blocked-off stuff in some cases). > And don't give me "it doesn't break anything" - in the past, I've fed at least > 2 bug fixes on things I found broken back to the grsecurity crew (one was a > borkage in the process-ID-randomization code, another was a bad parenthesis > matching breaking the intent of an 'if' in one of the filesystem protection > checks (symlink or fifo or something like that). Hmm? I found the PID rand breakage in 2.6.7's gr to be quite annoying and disabled it. It took me all of 2 minutes to determine that PID randomization was causing the breakage-- as I enabled it during boot with an init script, the machine oopsed several times and then panic'd. :) Heh, divide that 2 minutes by the thousands of people who look at the code, and you find bugs before they're created :D (j/k) - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9/dbhDd4aOud5P8RAokYAJ9oukytYsqBhz71RtzpC4o7K9od1QCfTRou ln0qF42yrB6+gi1Kt4YXudY= =75yE -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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, I don't force people to rewrite - I sadly don't have a cadre of slaves at my beck and call ;p), but it's also always a good idea to have interfaces that are bug-resistant even in the face of people actively not using the better interfaces. So having good interfaces that are harder to have bugs in does _not_ mean that we still shouldn't have defensive programming practices anyway. The combination of the two means that a bug in one layer hopefully gets caught be the other layer. Linus - 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: thoughts on kernel security issues
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 avoid design decisions that just drive every bug to be an inevitable security problem. 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-level code would be much simpler and not have to worry about things like buffer sizes and page boundaries. I don't know/remember if it actually fixed any security issues, but I'm confident it made them less likely, just by making it _easier_ to write code that doesn't have silly bounds problems. Linus - 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: thoughts on kernel security issues
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 split out. I could probably log 10,000 man-hours splitting up
> GrSecurity. :)
I'd try out Andrew's patch scripts if I were you. If you're making a patch to
the kernel, you'd best keep it in separate patches from the beginning, and
that's exactly what those scripts are very useful for.
> > It's also a lot easier to find the (inevitable) bugs. Either you already
> > have a clue ("try reverting that one patch") or you can do things like
> > binary searching. The bugs introduced a patch often have very little to do
> > with the thing a patch fixes - exactly because the patch _fixes_
> > something, it's been tested with that particular problem, and the new
> > problem it introduces is usually orthogonal.
>
> true. Very very true.
>
> With things like Gr, there's like a million features. Normally the
> first step I take is "Disable it all". If it still breaks, THEN THERE'S
> A PROBLEM. If it works, then the binary searching begins.
So how do you think you would do a binary search within big patches, if it
would take you 10,000 man-hours to split up the patch? Disabling a lot of
small patches is easy, disabling a part of a big one takes a lot more work.
> > Which is why lots of small patches usually have _different_ bug behaviour
> > than the patch they fix. To go back to the A+B fix: the bug they fix may
> > be fixed only by the _combination_ of the patch, but the bug they cause is
> > often an artifact of _one_ of the patches.
> >
>
> Wasn't talking about bugfixes, see above.
Oh, so you're saying that security fixes don't cause bugs? Great world you live
in, then...
> > IOW, splitting the patches up makes them
> > - easier to merge
> > - easier to verify
> > - easier to debug
> >
> > 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
> > this, since the bug you were trying to fix is the _one_ thing you are
> > really testing for).
>
> Lots of work to split up a patch though.
See above.
Sytse
-
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: thoughts on kernel security issues
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. You're > > thinking of fixing specific bugs; this is good and very important (as > > effective proactive security BREAKS things that are buggy), but there is > > a better way to create a more secure environment. Fixing the bugs > > increases the quality of the product, while adding protections makes > > them durable enough to withstand attacks targetting their own flaws. > > Adding protections for which no known threat exists is a waste of > time, effort, and adds to the kernel size. If you connect a machine > to a network, it can always get hit with so many broadcast packets > that it has little available CPU time to do useful work. Do we > add a network throttle to avoid this? If so, then you will hurt > somebody's performance on a quiet network. Everything done in > the name of "security" has its cost. The cost is almost always > much more than advertised or anticipated. > > > Try reading through (shameless plug) > > http://www.ubuntulinux.org/wiki/USNAnalysis and then try to understand > > where I'm coming from. > > 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 > that are disassembled on-board. Some ATM-slot, after decryption > is fed to a LAN so the sailors can have an Internet connection > for their lap-tops. The data took the same paths, but it's > completely independent and can't get mixed up no matter how > hard a hacker tries. Obviously you didn't hear about the secure network being hit by the "I love you" virus. The Navy doesn't INTEND to have any secure systems connected to a network to which any hackers could connect. Unfortunately, there will ALWAYS be a path, either direct, or indirect between the secure net and the internet. The problem exists. The only to protect is to apply layers of protection. And covering the possible unknown errors is a good way to add protection. - 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: thoughts on kernel security issues
-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, but also to mitigate the ones we don't >>know about. To truly mitigate any security flaw, we must make a >>non-circumventable protection. > > > To the extent that this means "if you see a bug, fix the bug, even if it's > unrelated" I agree completely. > That's the old, old, OLD method. :) It's a fundamental principle of good programming, a good one that some people (*cough*Microsoft*Cough*) have forgotten, and we see the results and know not to forget it ourselves. But I also like to go beyond that, to the extent that if you toss a wrench in it, it'll sieze up, but won't break. Some of this is userspace, and some is kernelspace. It's possible to fix userspace problems like code injection and tempfile races with kernel level policies on memory protections and filesystem intrinsics (symlink/hardlink rules). I believe that these and similar concepts should be explored, so that we can truly progress rather than simply continue in the archaic manner that we use today. Eventually we will evolve from "look for security vulns and fix them before they're exploited" to "fix unhandled security vulns first, and treat handled vulns as normal bugs." That is, we'll still fix the bugs; but we'll have a much smaller range of bugs that are actually exploitable, and thus a better, smaller, more refined set of high-priority focus issues. We already do this with everything else. The kernel developers, both LKML and external projects, have and are still exploring new schedulers for disk, IO, and networking; new memory managment and threading models; and new security concepts. We have everything from genetics algorithms to binary signing on the outside, as well as a O(1) CPU scheduler and security hook framework in vanilla. I want things to just continue moving. It's interesting to me mainly that something like 80% of the USNs Ubuntu puts out contain exploits that could only manage to be used as DoS attacks if the right systems were put in place, only counting the ones I actually know and understand myself. Not all of those protections are kernel-based, but the kernel based ones 'should' touch on each exploit in some way. I believe these are suitable for widespread deployment, so of course my idea of progress includes widespread deployment of these :) It's not entirely relavent to argue this here, but it gives me something to do while I'm extremely bored (hell I've even done an LSM clone that's simpler and implements full stacking just to occupy myself). Hopefully the Ubuntu developers deploy and run this stuff, so after being around 4-6 years, the merits of some often overlooked systems will finally be widely demonstrated and assessable. - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9ucWhDd4aOud5P8RAt57AJwNGyBm9jn87da+JJCbnYXQp+KH4QCbBupJ mEPqyDIE7ZZitAG1tTKo4qI= =rCVA -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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 security flaw, we must make a > non-circumventable protection. To the extent that this means "if you see a bug, fix the bug, even if it's unrelated" I agree completely. -- bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc Doing interesting things with little computers since 1979. - 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: thoughts on kernel security issues
-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: >>> -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 you lock both, then you (finally) create a >> problem for an intruder. >> >> That is to say, patch A will apply and work without B; patch B will >> apply and work without patch A; but there's no real gain from using >> either without the other. > > > > 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 the real world yes. On the computer, the front and back doors are half-consumed by a short-path wormhole that places them right next to eachother, so not really. :) >>> >>> >>> Then one might argue that doing any security patches is meaningless >>> because, as with bugs, there will always be some other hole not >>> covered by both A and B so why bother? >>> >> >> I'm not talking about bugs, I'm talking about mitigation of unknown bugs. >> >> You have to remember that I think mostly in terms of proactive security. >> If there's a buffer overflow, temp file race condition, code injection >> or ret2libc in a userspace program, it can be stopped. this narrows >> down what exploits an attacker can actually use. >> >> 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 left with mostly very short windows that are >> far and few, and thus may be beyond his level of UNION(task->skill, >> task->luck) in many cases. >> >> 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 security flaw, we must make a >> non-circumventable protection. >> > > So you intend to make so many changes to the kernel that a > previously thought-out exploit may no longer be workable? > > A preemptive strike, so to speak? No thanks, to quote Frank > Lanza of L3 communications; "Better is the enemy of good enough." > No, like this. You have a race condition, let's say. This is fairly common. Race conditions work because you generate a unique tempfile directory, create it, check to see if this tempfile exists in it, it doesn't, so you create it. Problem is, someone's symlinked or hardlinked another file into that temp directory, which you can write to but they can't; and you wind up opening the file and trashing it, or erasing it by creating over it. So, simple fix. 1) If the directory is +t,o+w, and the symlink is not owned by you, and the symlink is not owned by the owner of the directory, you can't follow the symlink. 2) If you try to make a hardlink (ln) to a file you don't own, permission is denied, unless you've got CAP_FOWNER and uid==0. Now, root tries to traverse /tmp/root/tmp4938.193a -> /etc/fstab, and gets permission denied. This is a real solution to race conditions (it's in GrSecurity). It's not "so many changes that previously thought-out exploits are no longer workable," it's a change in policy to remove conditions necessary for any future exploit of this class to be workable. >> If you can circumvent protection A by simply using attack B* to disable >> protection A to do more interesting attack A*, then protection A is >> smoke and mirrors. If you have protection B that stops B*, but can be >> circumvented by A*, then deploying A and B will reciprocate and prevent >> both A* and B*, creating a protection scheme that can't be circumvented. >> > > It makes sense to add incremental improvements to security as > part of the normal maturation of a product. It does not make > sense to dump a new pile of snakes in the front yard because > that might keep the burglars away. Snakes like passwords, or like a DAC system, or like SELinux MAC policies, or like preventing tasks from reading or altering eachothers' memory space? > >> In this context, it doesn't make sense to deploy a protection A or B >> without the companion protection, which is what I meant. You're >> thinking of fixing specific bugs; this is good and very im
Re: thoughts on kernel security issues
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 > > this, since the bug you were trying to fix is the _one_ thing you are > > really testing for). > > Lots of work to split up a patch though. Exactly. And since that's a prerequisite for any meaningful review, some equivalent of that work will have to be done at some point. The only question is who will be doing that work - proponents of patch or reviewers? Look at it that way: when you are submitting a paper for publication, it's your responsibility to get it into form that would allow review. Sending a lump of something that might, given considerable efforts, be massaged into readable and understandable text is not going to fly. And doing that with "it's a lot of work [so could reviewers please do that work themselves and spare me the efforts]" as rationale... - 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: thoughts on kernel security issues
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 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. That is to say, patch A will apply and work without B; patch B will apply and work without patch A; but there's no real gain from using either without the other. 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 the real world yes. On the computer, the front and back doors are half-consumed by a short-path wormhole that places them right next to eachother, so not really. :) Then one might argue that doing any security patches is meaningless because, as with bugs, there will always be some other hole not covered by both A and B so why bother? I'm not talking about bugs, I'm talking about mitigation of unknown bugs. You have to remember that I think mostly in terms of proactive security. If there's a buffer overflow, temp file race condition, code injection or ret2libc in a userspace program, it can be stopped. this narrows down what exploits an attacker can actually use. 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 left with mostly very short windows that are far and few, and thus may be beyond his level of UNION(task->skill, task->luck) in many cases. 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 security flaw, we must make a non-circumventable protection. So you intend to make so many changes to the kernel that a previously thought-out exploit may no longer be workable? A preemptive strike, so to speak? No thanks, to quote Frank Lanza of L3 communications; "Better is the enemy of good enough." If you can circumvent protection A by simply using attack B* to disable protection A to do more interesting attack A*, then protection A is smoke and mirrors. If you have protection B that stops B*, but can be circumvented by A*, then deploying A and B will reciprocate and prevent both A* and B*, creating a protection scheme that can't be circumvented. It makes sense to add incremental improvements to security as part of the normal maturation of a product. It does not make sense to dump a new pile of snakes in the front yard because that might keep the burglars away. In this context, it doesn't make sense to deploy a protection A or B without the companion protection, which is what I meant. You're thinking of fixing specific bugs; this is good and very important (as effective proactive security BREAKS things that are buggy), but there is a better way to create a more secure environment. Fixing the bugs increases the quality of the product, while adding protections makes them durable enough to withstand attacks targetting their own flaws. Adding protections for which no known threat exists is a waste of time, effort, and adds to the kernel size. If you connect a machine to a network, it can always get hit with so many broadcast packets that it has little available CPU time to do useful work. Do we add a network throttle to avoid this? If so, then you will hurt somebody's performance on a quiet network. Everything done in the name of "security" has its cost. The cost is almost always much more than advertised or anticipated. Try reading through (shameless plug) http://www.ubuntulinux.org/wiki/USNAnalysis and then try to understand where I'm coming from. 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 that are disassembled on-board. Some ATM-slot, after decryption is fed to a LAN so the sailors can have an Internet connection for their lap-tops. The data took the same paths, but it's completely independent and can't get mixed up no matter how hard a hacker tries. Cheers, Dick Johnson Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED]
Re: thoughts on kernel security issues
-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 fix the exploit. If say 80% of exploits are suddenly >>non-exploitable, then he's left with mostly very short windows that are >>far and few, and thus may be beyond his level of UNION(task->skill, >>task->luck) in many cases. > > > Correct. > > > >>If you can circumvent protection A by simply using attack B* to disable >>protection A to do more interesting attack A*, then protection A is >>smoke and mirrors. > > > You however missed an important case here. If attack B is outside > UNTION(task->skill, task->luck) protection A is *NOT* smoke-and-mirrors. > > And for the *vast* majority of attackers, if they have a canned exploit for > A and it doesn't work, they'll be stuck because B is outside their ability. Yes, true; but someone wrote that canned exploit for them, so the actual exploit writers will just adapt. Those attackers I don't think write their own exploits normally :) - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9rMqhDd4aOud5P8RAgXBAJ9vOzRSZUsxmFOo9W7fROhfq1IBvgCcCINx gTiTNm44vp/hlygaPTdy9UM= =tDcw -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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 left with mostly very short windows that are > far and few, and thus may be beyond his level of UNION(task->skill, > task->luck) in many cases. Correct. > If you can circumvent protection A by simply using attack B* to disable > protection A to do more interesting attack A*, then protection A is > smoke and mirrors. You however missed an important case here. If attack B is outside UNTION(task->skill, task->luck) protection A is *NOT* smoke-and-mirrors. And for the *vast* majority of attackers, if they have a canned exploit for A and it doesn't work, they'll be stuck because B is outside their ability. pgp0Wvq3IXZWi.pgp Description: PGP signature
Re: thoughts on kernel security issues
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 involve many hours of work, by more people than just the submitter. I highly recommend Andrew Morton's patch scripts, or something similar. http://www.zip.com.au/~akpm/linux/patches/ --b. - 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: thoughts on kernel security issues
-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 the introduction of new code into logical steps is still > helpful for people trying to understand the new code. > > Even if it's true that it's no use locking any door until they are all > locked, there's still some value to allowing people to watch you lock > each door individually. It's easier for them to understand what you're > doing that way. > I guess so. 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 > --Bruce Fields > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9qw3hDd4aOud5P8RAq+AAJ4ynZrASPcnh87ziZ1ZWrmzF9V44gCdHQXh yZQ7Z9J7gJ4GWr3zaXM6Qx8= =/4Ze -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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 to understand the new code. Even if it's true that it's no use locking any door until they are all locked, there's still some value to allowing people to watch you lock each door individually. It's easier for them to understand what you're doing that way. --Bruce Fields - 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: thoughts on kernel security issues
-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 testing them, _will_ be discouraged by locking the front door.
[...]
>
>>>Never mind that he still could have gotten in. After all, if you locked
>>>the back door too, he might still have a crow-bar.
>>
>>Crowbars don't work in computer security.
>
>
> Sure they do. They're the brute-force password-cracking. They're the
> physical security of the machine. They are any number of things.
>
> The point being that you will always have holes. Arguing for "there's
> another hole" is _never_ an argument against a small patch fixing one
> problem.
>
Not what I meant.
http://www.ubuntulinux.org/wiki/USNAnalysis
I'm more focused on this sort of security. Finding and fixing bugs is
important, but protecting against the exploitation of certain classes of
bugs is also a major step forward.
> Take it from me - I've been reviewing patches for _way_ too long. And it's
> a damn lot easier to review 100 small patches that do simple things and
> that have been split up and explained individually byt he submitter than
> it is to review 10 big ones.
>
Yeah I noticed. I'm trying to grep through the grsecurity megapatch and
write an LSM clone (stackable already) based on those hooks to
reimplement GrSecurity, as an academic learning experience. I try to
make something functional at each step (I did linking restrictions
first), but it's hard to find everything in that gargantuant thing
related to a specific feature :)
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 split out. I could probably log 10,000 man-hours splitting up
GrSecurity. :)
> It's also a lot easier to find the (inevitable) bugs. Either you already
> have a clue ("try reverting that one patch") or you can do things like
> binary searching. The bugs introduced a patch often have very little to do
> with the thing a patch fixes - exactly because the patch _fixes_
> something, it's been tested with that particular problem, and the new
> problem it introduces is usually orthogonal.
true. Very very true.
With things like Gr, there's like a million features. Normally the
first step I take is "Disable it all". If it still breaks, THEN THERE'S
A PROBLEM. If it works, then the binary searching begins.
>
> Which is why lots of small patches usually have _different_ bug behaviour
> than the patch they fix. To go back to the A+B fix: the bug they fix may
> be fixed only by the _combination_ of the patch, but the bug they cause is
> often an artifact of _one_ of the patches.
>
Wasn't talking about bugfixes, see above.
> IOW, splitting the patches up makes them
> - easier to merge
> - easier to verify
> - easier to debug
>
> 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
> this, since the bug you were trying to fix is the _one_ thing you are
> really testing for).
Lots of work to split up a patch though.
>
> See?
>
> Linus
>
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB9qX3hDd4aOud5P8RAlMGAJ0cXEbY1QALk6EyfCNJDE26FdRYLQCdGOQB
799/tZxwWQkpv+a/eavf4EY=
=GQR6
-END PGP SIGNATURE-
-
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: thoughts on kernel security issues
-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: >>> >>> 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. That is to say, patch A will apply and work without B; patch B will apply and work without patch A; but there's no real gain from using either without the other. >>> >>> >>>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 the real world yes. On the computer, the front and back doors are >>half-consumed by a short-path wormhole that places them right next to >>eachother, so not really. :) >> > > > Then one might argue that doing any security patches is meaningless > because, as with bugs, there will always be some other hole not > covered by both A and B so why bother? > I'm not talking about bugs, I'm talking about mitigation of unknown bugs. You have to remember that I think mostly in terms of proactive security. If there's a buffer overflow, temp file race condition, code injection or ret2libc in a userspace program, it can be stopped. this narrows down what exploits an attacker can actually use. 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 left with mostly very short windows that are far and few, and thus may be beyond his level of UNION(task->skill, task->luck) in many cases. 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 security flaw, we must make a non-circumventable protection. If you can circumvent protection A by simply using attack B* to disable protection A to do more interesting attack A*, then protection A is smoke and mirrors. If you have protection B that stops B*, but can be circumvented by A*, then deploying A and B will reciprocate and prevent both A* and B*, creating a protection scheme that can't be circumvented. In this context, it doesn't make sense to deploy a protection A or B without the companion protection, which is what I meant. You're thinking of fixing specific bugs; this is good and very important (as effective proactive security BREAKS things that are buggy), but there is a better way to create a more secure environment. Fixing the bugs increases the quality of the product, while adding protections makes them durable enough to withstand attacks targetting their own flaws. Try reading through (shameless plug) http://www.ubuntulinux.org/wiki/USNAnalysis and then try to understand where I'm coming from. - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9qRchDd4aOud5P8RAv74AJ9zvphwU8c7tX1bTa1YwofVJYxligCbBkgN hLg9othWu96Oc+w47PI7+b0= =XLFq -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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 the real world yes. On the computer, the front and back doors are
> half-consumed by a short-path wormhole that places them right next to
> eachother, so not really. :)
No, the same is true even when the doors are right next to each other.
A lot of worms etc depend on automation, and do one or a few very specific
things. If one of them doesn't work (not because the computer is _secure_
mind you, just some random thing), it's already a more secure setup.
And even if two independent security bugs cause _exactly_ the same
symptoms (ie the exact same exploit works even if either of the bugs still
remain), having two independent patches that fix them is STILL better.
Just because the explanation of them is simpler, and the verification of
them is simpler.
> > Never mind that he still could have gotten in. After all, if you locked
> > the back door too, he might still have a crow-bar.
>
> Crowbars don't work in computer security.
Sure they do. They're the brute-force password-cracking. They're the
physical security of the machine. They are any number of things.
The point being that you will always have holes. Arguing for "there's
another hole" is _never_ an argument against a small patch fixing one
problem.
Take it from me - I've been reviewing patches for _way_ too long. And it's
a damn lot easier to review 100 small patches that do simple things and
that have been split up and explained individually byt he submitter than
it is to review 10 big ones.
It's also a lot easier to find the (inevitable) bugs. Either you already
have a clue ("try reverting that one patch") or you can do things like
binary searching. The bugs introduced a patch often have very little to do
with the thing a patch fixes - exactly because the patch _fixes_
something, it's been tested with that particular problem, and the new
problem it introduces is usually orthogonal.
Which is why lots of small patches usually have _different_ bug behaviour
than the patch they fix. To go back to the A+B fix: the bug they fix may
be fixed only by the _combination_ of the patch, but the bug they cause is
often an artifact of _one_ of the patches.
IOW, splitting the patches up makes them
- easier to merge
- easier to verify
- easier to debug
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
this, since the bug you were trying to fix is the _one_ thing you are
really testing for).
See?
Linus
-
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: thoughts on kernel security issues
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 > >>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. > >> > >>That is to say, patch A will apply and work without B; patch B will > >>apply and work without patch A; but there's no real gain from using > >>either without the other. > > > > > > 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 the real world yes. On the computer, the front and back doors are > half-consumed by a short-path wormhole that places them right next to > eachother, so not really. :) > Then one might argue that doing any security patches is meaningless because, as with bugs, there will always be some other hole not covered by both A and B so why bother? -- Dmitry - 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: thoughts on kernel security issues
-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 you lock both, then you (finally) create a >>problem for an intruder. >> >>That is to say, patch A will apply and work without B; patch B will >>apply and work without patch A; but there's no real gain from using >>either without the other. > > > 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 the real world yes. On the computer, the front and back doors are half-consumed by a short-path wormhole that places them right next to eachother, so not really. :) > Never mind that he still could have gotten in. After all, if you locked > the back door too, he might still have a crow-bar. > Crowbars don't work in computer security. The most you can do is slow the machine down by infinite network requests or CPU hogging (web server requests take CPU, even to reject) if *everything* else is perfect; but the goal is to keep them out, since we live in reality and not fairyland where we can even stop DDoSes from eating network BW. > It is a logically fallacy to think that "perfect" is good. It's not. > Anybody who strives for perfection will FAIL. > No, you aim close. You won't hit it, but you'll get close. > What's good is "incremental changes". Something that everybody and his dog > can look at for five seconds and say "oh, that's obviously fine", and then > can get more testing (because "everybody and his dog" saying "that's fine" > doesn't actually prove much of anything). > > This has nothing to do with security, btw. It's universally true. You get > absolutely nowhere by trying to redesign the world. > yeah, I'm just very security minded. Don't mind me much. > Linus > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD4DBQFB9pHWhDd4aOud5P8RAoDBAJwIrXSd5Z6uDUoFFBUWP4y/0m/TLgCYrcEa Qu0RrJrCbo4A0OCj8im4JQ== =6pZA -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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. > > That is to say, patch A will apply and work without B; patch B will > apply and work without patch A; but there's no real gain from using > either without the other. 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. Never mind that he still could have gotten in. After all, if you locked the back door too, he might still have a crow-bar. It is a logically fallacy to think that "perfect" is good. It's not. Anybody who strives for perfection will FAIL. What's good is "incremental changes". Something that everybody and his dog can look at for five seconds and say "oh, that's obviously fine", and then can get more testing (because "everybody and his dog" saying "that's fine" doesn't actually prove much of anything). This has nothing to do with security, btw. It's universally true. You get absolutely nowhere by trying to redesign the world. Linus - 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: thoughts on kernel security issues
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, but even then you can split it out so that one patch does _only_ that part, and is verifiable as doing only that part. It's also pretty rare. We've had a few big ones like that, notably when moving a BKL around (moving it from the VFS layer down into each individual filesystem). And I can't see that really happening in a security-only patch. Linus - 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: thoughts on kernel security issues
-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 on its own. You do not have >> to make A+B be one patch. > > > 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. > Actually, the issue I was looking at was more focused on security patches which implement multiple security countermeasures which do precisely dick; except that they cover eachothers' flaws so that together they create a real solution. 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. That is to say, patch A will apply and work without B; patch B will apply and work without patch A; but there's no real gain from using either without the other. > Did I say it more clearly? Some things, like locks, have to have all the > players using the same rules. > >> >> >>> There is no really good way (AFAIK) to submit a bunch of patches and >>> say "if any one of these is rejected the whole thing should be ignored." >> >> >> >> But that's done ALL THE TIME. Claiming that there is no good way is >> not only disingenious (we call them "numbers", and they start at 1, go >> to 2, then 3. Then there's usually a 0-patch which only contains >> explanations of the series), but it's clearly not true, since we have >> patches like that weekly. > > > Again, I said later that it depends on the maintainer not to apply one > part which won't work without the others. Not that it wasn't happening, > but that there's nothing more formal than human talent. I don't regard > that as a really good way, since it makes more work for maintainers. > > I really think the original post was reasonably clear that I was > suggesting a more formal means of designating things which should be > accepted as a unit, not whatever you rea into it. > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB9ol1hDd4aOud5P8RApVuAJ4jPnFcRGp7hThvmDefm6yUaDB4VACeOrqH bSD9P/v/lyJiIZ675QJfFqY= =EgxJ -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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 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. Did I say it more clearly? Some things, like locks, have to have all the players using the same rules. There is no really good way (AFAIK) to submit a bunch of patches and say "if any one of these is rejected the whole thing should be ignored." But that's done ALL THE TIME. Claiming that there is no good way is not only disingenious (we call them "numbers", and they start at 1, go to 2, then 3. Then there's usually a 0-patch which only contains explanations of the series), but it's clearly not true, since we have patches like that weekly. Again, I said later that it depends on the maintainer not to apply one part which won't work without the others. Not that it wasn't happening, but that there's nothing more formal than human talent. I don't regard that as a really good way, since it makes more work for maintainers. I really think the original post was reasonably clear that I was suggesting a more formal means of designating things which should be accepted as a unit, not whatever you rea into it. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: thoughts on kernel security issues
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 patches and > say "if any one of these is rejected the whole thing should be ignored." But that's done ALL THE TIME. Claiming that there is no good way is not only disingenious (we call them "numbers", and they start at 1, go to 2, then 3. Then there's usually a 0-patch which only contains explanations of the series), but it's clearly not true, since we have patches like that weekly. In the last seven days the kernel mailing list has seen at least four such series where patches depend at least partly on each other: - Kay Sievers: driver core: export MAJOR/MINOR to the hotplug (0-7) - Andreas Gruenbacher: NFSACL protocol extension for NFSv3 (0-13) - Roland Dreier: InfiniBand updates for 0-12 - Roland McGrath: per-process timers (1-7) and that was from just a quick look. It seems to be almost a daily occurrence. In short: listen to Arjan, because he is wise. And stop making totally idiotic excuses that are clearly not true. Linus - 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: thoughts on kernel security issues
[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 reciprocating combinations of each protection can protect the others from being exploited and create a truly secure environment. OK, for those who tuned in late to the telecast of "Kernel Development Process for Newbies": It *DOES NOT MATTER* that PaX and ES "don't make sense" split out into 5 or 6 pieces. We merge in stuff *ALL THE TIME* in 20 or 30 chunks, where it doesn't make any real sense unless all 20 or 30 go in. Just today, there was a 29-patch monster replacing kexec, and another 12-patcher replacing something else. And I don't think anybody claims that many of those 29 patches stand totally by themselves. You install 25 of them, you probably don't have a working kexec, which is the goal of the patch series. The point is that *each* of those 29 patches is small and self-contained enough to review for breakage of current stuff, elegance of coding, and so on. Now let's look at grsecurity: % wc grsecurity-2.1.0-2.6.10-200501071049.patch 23539 89686 700414 grsecurity-2.1.0-2.6.10-200501071049.patch 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 single patch that big. 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 they merged? Because they showed up in 4-8K chunks. Split-out portions of PaX (and of ES) don't make sense. ASLR can be evaded pretty easily: inject code, read %efp, find the GOT, read addresses. The NX protections can be evaded by using ret2libc. on x86, you need emulation to make an NX bit or the NX protections are useless. So every part prevents every other part from being pushed gently aside. Right. But if you *submit* them as "a chunk to add x86 emulation of an NX bit", "a chunk to add ASLR", "a chunk to add NX", "a chunk to do FOO with the vsyscall page", and so on, they might actually have a snowball's chance of being included. If nothing else, the fact they're posted as different patches means each can be used as the anchor for a thread discussing the merits of *that* patch. Adrian Bunk has been submitting patches for the last several weeks which probably total *well* over the size of the PAX patch. And since they show up as separate patches, the non-controversial ones can sail by, the ALSA crew can comment when he hits an ALSA module, the filesystem people can comment when he hits one of their files, and so on. Unfortunately if A depends on B to work at all, you have to put A and B in as a package. There is no really good way (AFAIK) to submit a bunch of patches and say "if any one of these is rejected the whole thing should be ignored." While akpm and others do a great job of noting related parts, that's not the ideal solution. Ideally the monolithic patch should be checked in parts by the people you mention, or there should be an "all or nothing" protocol better than dropping the responsibility on the maintainer. Adding and vetting things in stages works only when the parts work independently, and that's not always the case. You don't leap vast chasms in small cautious steps. -- bill davidsen <[EMAIL PROTECTED]> CTO TMR Associates, Inc Doing interesting things with small computers since 1979 - 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: thoughts on kernel security issues
-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 security figure and/or haven't donated your life to security and >>forsaken all lovers before it like Joshua Brindle or Brad Spengler or >>whoever the anonymous guy who developes PaX is. I guess less focus on >>the developer and more focus on the development. > > > But Ingo is someone who > > - is a known allround kernel hacker > - has a trackrecord of getting things done that actually get used > - lowlevel CPU knowledge > - is able to comunicate with other developers very well > - is able to make good tradeoffs > - has taste > > most of that can't be said for your personal heroes > That's all good, but I notice being exceedingly competant in the needs of a proper secured environment is lacking in your list. Is he exceedingly knowledgible about security? Who is he working with who will fill in his gaps in understanding if not? The PaX developer may not be well known, or have anything in the kernel, but I've talked to the guy. He has CPU manuals for practically everything, and *gasp* he READS them! He maintains PaX himself, and it works well on my AMD64; he has the manual, but not the CPU. The trade-off of SEGMEXEC is 50% of VM space and 0.7% CPU. The trade-off of PAGEEXEC (on x86; a real NX bit is used on other CPUs) is identical to Exec Shield's until that method fails, then it falls back to a potentially very painful CPU trade-off that's necessary to continue to offer a supported NX bit. Explain "Taste." > >>*shrug* The kernel's basic initialization code is in assembly. On 40 >>different platforms. That's pretty complex in terms of kernel code, >>which is 99.998% C. > > > No, the kernel initialization is not complex at all. complexity != code size > I was more pointing out that it was assembler code. Clean and simple as it may be, you come back in 10 years and try to maintain it. > >>Which brings us to a point on (1) and (2). You and others continue to >>pretend that SEGMEXEC is the only NX emulation in PaX. I should remind >>you (again) that PAGEEXEC uses the same method that Exec Shield uses >>since I believe kernel 2.6.6. In the cases where this method fails, it >>falls back to kernel-assisted MMU walking, which can produce potentially >>high overhead. > > > You stated that a few time. Now let's welcome you to reality: > > - Linus doesn't want to make the tradeoffs for segment based NX-bit >emulation in mainline at all It's an option, set in menuconfig. It's not a forced trade-off, so integrating it (btw I wasn't and am not currently arguing to get PaX integrated) wouldn't really force a trade-off on the user. Back to the above, this argument doesn't cover page-based NX-bit emulation. > - Ingo and his collegues at Red Hat want to have it, but they don't >want to break application nor introduce the addition complexity >of the PaX code. > Nor guarantee that the NX emulation is actually durable. > Is is that hard to understand? > > What's hard to understand is the constant banter about SEGMEXEC when there's a second mode AND when it's completely optional. Are you trying to make it sound like you're pretending that PaX isn't innovative and that the trade-offs are obscene and infeasible in an every-day environment? Why is PAGEEXEC ignored in every argument, and SEGMEXEC focused on, when one or both can be disabled so that the VM split goes away? Could it be that you can't argue against PAGEEXEC because it uses the exact same method that Exec Shield uses, and falls back to a heavier one when that fails; yet you argue that Exec Shield shouldn't fail except in extremely rare cases, so you can't hold the possibly heavy-overhead case in PAGEEXEC to question without invalidating your own arguments? What's wrong with PAGEEXEC? Why focus on SEGMEXEC? The only thing I ever complain about concerning Exec Shield's principle implementation is that it can fail in certain conditions. the deployment side (PT_GNU_STACK and automated marking) I don't even know why I touched on; perhaps I should try to separate ES from RedHat's overall smoke-and-mirrors approach to security, since ES at least supplies a partially functional and reciprocating NX-ASLR proteciton. - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB8CGphDd4aOud5P8RAlq/AJ40TYCxoUMi2PsWvZz/BqHsugEnuQCeL5iC y2Ot5pTwi+1dbPKN+6WYU4k= =Weu3 -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo
Re: thoughts on kernel security issues
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 lovers before it like Joshua Brindle or Brad Spengler or > whoever the anonymous guy who developes PaX is. I guess less focus on > the developer and more focus on the development. But Ingo is someone who - is a known allround kernel hacker - has a trackrecord of getting things done that actually get used - lowlevel CPU knowledge - is able to comunicate with other developers very well - is able to make good tradeoffs - has taste most of that can't be said for your personal heroes > *shrug* The kernel's basic initialization code is in assembly. On 40 > different platforms. That's pretty complex in terms of kernel code, > which is 99.998% C. No, the kernel initialization is not complex at all. complexity != code size > Which brings us to a point on (1) and (2). You and others continue to > pretend that SEGMEXEC is the only NX emulation in PaX. I should remind > you (again) that PAGEEXEC uses the same method that Exec Shield uses > since I believe kernel 2.6.6. In the cases where this method fails, it > falls back to kernel-assisted MMU walking, which can produce potentially > high overhead. You stated that a few time. Now let's welcome you to reality: - Linus doesn't want to make the tradeoffs for segment based NX-bit emulation in mainline at all - Ingo and his collegues at Red Hat want to have it, but they don't want to break application nor introduce the addition complexity of the PaX code. Is is that hard to understand? - 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: thoughts on kernel security issues
-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 easier in most cases to automate-and-review, but it still has >>to be done. I think in the case of PaX markings, the maintenance >>overhead of manually marking binaries is minimal enough that looking for >>mistakes would be more work than working from an already known and >>familiar base. > > > > well, marking with PT_GNU_STACK is similar, execstack tool (part of the > prelink package) both shows and can change the existing marking of > binaries/libs. > > How is that much different to what pax provides? > > The point was more that it's easier to avoid embarasments like "What? Plug-ins are marked PT_GNU_STACK, but don't need it? Firefox is a high risk application and we're giving it an executable stack needlessly?! SOMEBODY TOLD WIRED THIS?! *IT'S ON SLASHDOT?!!?!!?*" when you do ALL of the marking manually, so that you know who has what. The reason for this is that rather than check every marking on every program (and library in the ES case), you just run each program. You do run each program right? Or is your distribution's QA shit? I'd hope you test each program carefully to make sure it actually works. So this should be normal anyway. When you run into an ES or PaX problem, you know to track it down and mark it. No accidental mismarking setting things less secure than they have to be. I usually encourage deploying a new security system like SSP, PaX, or the use of PIE binaries across everything on the development boxes, and then cleaning up the breakage. The reason for this is that you quickly--without having to second-guess an automatic marking system or specifically examine each program in testing separated from your normal QA--locate ALL breakage in your normal QA testing routine AND come out with the tightest security settings possible. (On the same note, never ever make a release with protections you haven't actually tested.) > > > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB8APmhDd4aOud5P8RAgQmAJ9f/Li0fj1+w1RH2bpCmIurZWidBACfbpvN ITRMox6SIRt1qLsRP3ykUF0= =Q22O -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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 doesn't mean that it's suitable for inclusion in something like RedHat where it's almost certain to cause a problem for *some* user. > > [ 3) requires manual tagging of applications. ] > > > > Good. Maybe distributors will actually know what they're talking about > when flapping their mouths, rather than say "Oh look PaX it's magic so > we just need to turn it on!" Even I (at user level) examine everything > I'm using and try to understand it; I don't expect all users to do this, > but the distribution has to. OK.. but then you say... > PT_GNU_STACK is actually explicitly disabled -- apparently this is hard > work, as my distribution can't seem to always keep up with it or get it > quite right. Can you explain why your distro has difficulty getting PT_GNU_STACK 100% right, but you expect them to get tagging of apps with a flag that has almost identical semantics to PT_GNU_STACK correct? pgpllo73hQmU3.pgp Description: PGP signature
Re: thoughts on kernel security issues
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 think in the case of PaX markings, the maintenance > overhead of manually marking binaries is minimal enough that looking for > mistakes would be more work than working from an already known and > familiar base. well, marking with PT_GNU_STACK is similar, execstack tool (part of the prelink package) both shows and can change the existing marking of binaries/libs. How is that much different to what pax provides? - 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: thoughts on kernel security issues
-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 to > Linux so i'm not sure what to make of your comment :-| Here's a list of > bigger stuff i worked on in the past 3-4 years: > > http://redhat.com/~mingo/ > > as you can readily notice from the directory names alone, 'preemption > and schedulers' is pretty much in the minority :-| > > and that list i think sums up the main difference in mindset: to me, > exec-shield is 'just' another kernel feature (amongst dozens), which > solves a problem. I'm not attached to the concept/patch emotionally, i > only want to see a solution for a problem in a pragmatic way. Playing > with lowlevel segment details is not nice and not always fun and results > in tradeoffs i dont like, but it's pretty much the only technique that > works on older x86 CPUs (as PaX has proven it too). If something better > comes along, then more power to it. > > 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 lovers before it like Joshua Brindle or Brad Spengler or whoever the anonymous guy who developes PaX is. I guess less focus on the developer and more focus on the development. >>[...] but I honestly think PaX is the better technology, and I think >>it's important that the best security technology be in place. [...] > > > i like PaX's completeness, and it has different tradeoffs. There is one > major and two medium tradeoffs that PaX has, from a distributor's POV: > > 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. > [ 2) the technique PaX uses (mirrored vmas) is pretty complex in terms > of MM code. ] > *shrug* The kernel's basic initialization code is in assembly. On 40 different platforms. That's pretty complex in terms of kernel code, which is 99.998% C. > [ 3) requires manual tagging of applications. ] > Good. Maybe distributors will actually know what they're talking about when flapping their mouths, rather than say "Oh look PaX it's magic so we just need to turn it on!" Even I (at user level) examine everything I'm using and try to understand it; I don't expect all users to do this, but the distribution has to. Once I was on the SELinux toy box (a honeypot-type thing) that Gentoo set up, with root. The first thing I did was run a 2-line shell command to scan for and inform me of any areas I could write to. I was only supposed to be able to write to /tmp, but I found 2 or 3 more. Holes in the Gentoo SELinux policy, which PeBenito fixed in about 2 minutes. He had to write that policy by hand. How bad do you think it'd have been--not just what I caught, but what I wouldn't have been able to catch with just a cursory look, maybe serious flaws--if the policy was automatically generated? I could only imagine auto-generated policy, drop-in, you think you're secure for a good long while. . . . 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 think in the case of PaX markings, the maintenance overhead of manually marking binaries is minimal enough that looking for mistakes would be more work than working from an already known and familiar base. Also, a modified toolchain spits out ELF binaries with -E when you need emutramp (I've seen this but I don't know if it's SOME or ALL cases), which is normally what causes you to need an executable stack. An automated tool could read the ELF header (ldd, readelf) and trace down all libraries for each program, looking for any with -E. If it finds one, it marks the program -E too. That only leaves a few points of breakage, particularly things like zsnes which need to mprotect() a huge hunk of assembly code to make it writable. > The technique exec-shield uses (to track the per-process 'highest > executable address') is pretty simple and non-intrusive on the > implementational level, but it also results in exec-shield's main > tradeoff: > >certain VM allocation patterns (e.g. doing mprotect() on an area that >was allocated not via PROT_EXEC and was thus mapped high) can reduce >exec-shield to 'only protects the stack against execution', or if >the application needs an executable stack then reduces exec-shield to >'no protection'. > Which brings us to a point on (1) and (2). You and others continue to pretend that SEGMEXEC is the only NX emulation in PaX. I should remind you
Re: thoughts on kernel security issues
* 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 stuff i worked on in the past 3-4 years: http://redhat.com/~mingo/ as you can readily notice from the directory names alone, 'preemption and schedulers' is pretty much in the minority :-| and that list i think sums up the main difference in mindset: to me, exec-shield is 'just' another kernel feature (amongst dozens), which solves a problem. I'm not attached to the concept/patch emotionally, i only want to see a solution for a problem in a pragmatic way. Playing with lowlevel segment details is not nice and not always fun and results in tradeoffs i dont like, but it's pretty much the only technique that works on older x86 CPUs (as PaX has proven it too). If something better comes along, then more power to it. > [...] but I honestly think PaX is the better technology, and I think > it's important that the best security technology be in place. [...] i like PaX's completeness, and it has different tradeoffs. There is one major and two medium tradeoffs that PaX has, from a distributor's POV: 1) the halving of the per-process VM space from 3GB to 1.5GB. [ 2) the technique PaX uses (mirrored vmas) is pretty complex in terms of MM code. ] [ 3) requires manual tagging of applications. ] The technique exec-shield uses (to track the per-process 'highest executable address') is pretty simple and non-intrusive on the implementational level, but it also results in exec-shield's main tradeoff: certain VM allocation patterns (e.g. doing mprotect() on an area that was allocated not via PROT_EXEC and was thus mapped high) can reduce exec-shield to 'only protects the stack against execution', or if the application needs an executable stack then reduces exec-shield to 'no protection'. it turns out these cases where exec-shield gets reduced are quite rare and dont happen in critical applications. (partly because we fixed affected critical applications - such fixes made sense even when not considering the exec-shield impact.) If a 'generic' distribution (i.e. one that has a significant userbase, has thousands of packages that do get used) deviates from mainline it wants to do it as simply as possible. (otherwise it would have the overhead of porting/testing those deviations all the time.) In fact, most of the extra patches that distribution kernels apply are patches that they think will go mainline soon. If they apply any patch they know wont be merged anytime soon they only do it if it is really needed, and even then they try chose the variant that is smaller and easier to maintain. Another important aspect is that extra patches should obviously _widen_ the utility of the system, not narrow it. On x86, VM space is scarce so PaX's halving of the VM space is a 'reduced utility' problem. (yes, you can turn it off per application and get processes that have 3GB of address space, but that removes security for those processes. Also, you cannot know in advance whether an application will use more than 1.5GB of VM - different systems have different usage patterns.) [ PaX's #2 tradeoff is a maintainance overhead issue. Not an insurmountable issue because it is well-written kernel code, but combined with #1 it can tip the scale. PaX's #3 tradeoff is fixable - it could very well use the PT_GNU_STACK code now upstream. ] you seem to be arguing for a 'no prisoners taken' approach to security, and that is a perfectly fine approach if you maintain your own variant of a distribution. the other approach to security (which Fedora follows) is to 'make it as seemless and automatic as possible, so that people actually end up using our stuff.' so while exec-shield is not "complete" in the sense of PaX, in practice it is like 99% complete. E.g. on my Fedora desktop box: $ lsexec --all | grep 'execshield enabled' | wc -l 86 $ lsexec --all | grep 'execshield disabled' | wc -l 0 and that's what really matters at the end of the day. (Anyway, you dont have to believe and/or follow any of this, you are free to run your own distribution, and if it's good then people will inevitably end up using it.) Ingo - 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: [Lists-linux-kernel-news] Re: thoughts on kernel security issues
* 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 developers. So he has not only read the code but has written portions of it. Ingo - 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: thoughts on kernel security issues
* 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 the NX bit - i.e. latest AMD and Intel CPUs. Let me quote from the commit log: http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED] [...] furthermore, the patch also implements 'NX protection' for kernelspace code: only the kernel code and modules are executable - so even kernel-space overflows are harder (in some cases, impossible) to exploit. Here is how kernel code that tries to execute off the stack is stopped: kernel tried to access NX-protected page - exploit attempt? (uid: 500) Unable to handle kernel paging request at virtual address f78d0f40 printing eip: ... implemented, split out and brought to you by yours truly, as part of the exec-shield project. (You know, the one not developed by that 'scheduler developer' ;-) Ingo - 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/
Splitting up grsecurity and PAX (was Re: thoughts on kernel security issues
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 train for the RBAC stuff, and so on. > > > > RBAC first. Some of the other stuff relies on the RBAC system, I'm > told. Not sure what. Well, there's 3 classes of stuff: 1) Stuff that's basically independent of RBAC (a lot of randomization stuff, for instance). These can go as a separate stream. 2) Stuff that is mostly independent of RBAC, but can use it for configuration and control. So for instance, the PAX stuff (which by itself is close to half the whole thing) could go in, and possibly with a "stub" patch that adds control via /proc/kernel/something or a /sys entry. And it's *OK* if your code has a "shim" in it to make patch 3 work until the new infrastructure that patch 27 adds shows up, meaning that patch 26 removes a big chunk of patch 3 (especially if your /sys shim stands on its own even without patch 27). 3) The stuff that literally makes *no* sense if you don't have RBAC. It may very well make sense to attack the stuff in group (1) *first*, because then (a) all the kernel users get the benefits (similar to the "non-exec-stack" patch from execshield - everybody wins from that piece even though it's not all of the package), and (b) it's an easy way to pile up street creds by demonstrating with small patches that you are with the program - when some of the later, more contentious patches show up, it helps if you're recognized as the guy who already sent in 10-15 patches... > I think GrSecurity's RBAC is a bit bigger than LSM can accomodate. Well - what parts of RBAC *can* be done inside the LSM framework? What parts could be done inside LSM if LSM gained another hook or two (there *is* precedent for adding a hook for things that can reasonably use it)? What parts can't be done inside LSM, and why? > Anyway, I wasn't originally trying to get PaX into mainline in this > discussion; I think this started out with me trying to point out why > things like PaX have to be all-or-nothing. I agree that the sum set of features eventually included needs to cover all the bases - the big hurdle is factoring it down into patches that stand a chance. pgpwWTZaqZ1O6.pgp Description: PGP signature
Re: thoughts on kernel security issues
-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 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 train for the RBAC stuff, and so on. > RBAC first. Some of the other stuff relies on the RBAC system, I'm told. Not sure what. > Keep in mind that properly segmented, *parts* of grsecurity have at least > a fighting chance - the fact that (for instance) mainline may reject the > way RBAC is implemented because it's not LSM-based doesn't mean that you > shouldn't at least try to get the PaX stuff in, and the randomization stuff, > and so on. > I think GrSecurity's RBAC is a bit bigger than LSM can accomodate. Anyway, I wasn't originally trying to get PaX into mainline in this discussion; I think this started out with me trying to point out why things like PaX have to be all-or-nothing. > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7ssKhDd4aOud5P8RAnVtAJ9f4YcAjLOEGkG7NOB7TBqJdnXD5QCfXwyZ ozuM56ETWpuOAvKUgXkmJrA= =+Hnj -END PGP SIGNATURE- - 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: thoughts on kernel security issues
[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 good projects that have failed just because they sat around saying "my stuff is better" without caring about how to merge it or without listening other kernel developers. Then someone reimplemented it better and submitted it in a way it could be handled, and listened to other developers, and it got in the kernel and everybody helped to make it better than the first alternative. Kbuild is a good examle of this So, if you want to have have PAX or grsecurity in the kernel, you probably should submit patches (in the way described in SubmittingPatches.txt) and if everybody agrees that it's better and you listen other developers and make changes accordingly and you don't say "$SOMEPERSON is just a scheduler developer" perhaps it'll be merged. Of course that's more difficult since people has already cared about doing all that work with ES and it's already working OK for thousand of people. - 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: thoughts on kernel security issues
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 they merged? Because they showed up in 4-8K chunks. > > > note to readers: I'm still not happy about the split up and want to > split this up even further in smaller pieces; the split up there is only > a first order split. Right - the point is that even an idiot like me can get my head wrapped around that biggest 7K chunk and figure out what's going on. On the other hand, even the Alan Cox gnome-cluster isn't able to digest a 280K patch... pgp74gjTlWAG5.pgp Description: PGP signature
Re: thoughts on kernel security issues
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 grsecurity (pid, port number, all the rest of those), a 50-60 patch train for the RBAC stuff, and so on. Keep in mind that properly segmented, *parts* of grsecurity have at least a fighting chance - the fact that (for instance) mainline may reject the way RBAC is implemented because it's not LSM-based doesn't mean that you shouldn't at least try to get the PaX stuff in, and the randomization stuff, and so on. pgpyCRryCgHgD.pgp Description: PGP signature
Re: thoughts on kernel security issues
-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 exploits" until someone takes 5 minutes >>to make a slight alteration. Only the reciprocating combinations of >>each protection can protect the others from being exploited and create a >>truly secure environment. > > > OK, for those who tuned in late to the telecast of "Kernel Development Process > for Newbies": > > It *DOES NOT MATTER* that PaX and ES "don't make sense" split out into 5 or > 6 pieces. We merge in stuff *ALL THE TIME* in 20 or 30 chunks, where it > doesn't make any real sense unless all 20 or 30 go in. Just today, there was > a 29-patch monster replacing kexec, and another 12-patcher replacing something > else. And I don't think anybody claims that many of those 29 patches stand > totally by themselves. You install 25 of them, you probably don't have a > working > kexec, which is the goal of the patch series. > > The point is that *each* of those 29 patches is small and self-contained > enough > to review for breakage of current stuff, elegance of coding, and so on. Now > let's look at grsecurity: > > % wc grsecurity-2.1.0-2.6.10-200501071049.patch > 23539 89686 700414 grsecurity-2.1.0-2.6.10-200501071049.patch > > 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 single patch that > big. > PaX is available for 2.6.10, but it's in the testing phase. I've had good results. > 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 they merged? Because they showed up in 4-8K chunks. > so you want 90-200 split out patches for GrSecurity? > >>Split-out portions of PaX (and of ES) don't make sense. ASLR can be >>evaded pretty easily: inject code, read %efp, find the GOT, read >>addresses. The NX protections can be evaded by using ret2libc. on x86, >>you need emulation to make an NX bit or the NX protections are useless. >>So every part prevents every other part from being pushed gently aside. > > > Right. But if you *submit* them as "a chunk to add x86 emulation of an NX > bit", "a chunk to add ASLR", "a chunk to add NX", "a chunk to do FOO with the > vsyscall page", and so on, they might actually have a snowball's chance of > being included. > > If nothing else, the fact they're posted as different patches means each can > be > used as the anchor for a thread discussing the merits of *that* patch. Adrian > Bunk has been submitting patches for the last several weeks which probably > total *well* over the size of the PAX patch. And since they show up as > separate patches, the non-controversial ones can sail by, the ALSA crew can > comment when he hits an ALSA module, the filesystem people can comment when he > hits one of their files, and so on. ok ok ok. I get the point: I'm the only person in the world who can swallow a twinkie whole, the rest of you need to chew. - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7r8UhDd4aOud5P8RAg6tAJ4uWXxFSVcLhfB/QwWcBR0rTS/WKgCcD5ga S1xb603WKqgk2Bq5/zhpSXw= =aHEb -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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 to". Without that capability set, you can only execute binaries that you cannot write to, and that you cannot _get_ write permission to (ie you can't be the owner of them either - possibly only binaries where the owner is root). How would you map that to interpreted languages? Bash may not be an issue (in general), but perl, java, SQL, etc, would be. People other than software developers do write in some of those. I realize people disagree with me, which is also why I don't in any way take vendor-sec as a personal affront or anything like that: I just think it's a mistake, and am very happy to be vocal about it, but hey, the fundamental strength of open source is exactly the fact that people don't have to agree about everything. That's true, but in practice an administrator who disagrees with a developer gets to maintain their own application or O/S, and most users have no recourse but to go to another O/S or app. Which makes it far more practical to explain a point than to storm off and do it yourself and have to maintain it forever. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - 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: thoughts on kernel security issues
> 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 single patch that > big. > > 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 they merged? Because they showed up in 4-8K chunks. > note to readers: I'm still not happy about the split up and want to split this up even further in smaller pieces; the split up there is only a first order split. - 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: thoughts on kernel security issues
> > > > 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 lots of reviews on it as a whole and worked on it for over a year in relation with putting it in the Fedora kernel etc etc. So yes I have read the code. signature.asc Description: This is a digitally signed message part
Re: thoughts on kernel security issues
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 combinations of > each protection can protect the others from being exploited and create a > truly secure environment. OK, for those who tuned in late to the telecast of "Kernel Development Process for Newbies": It *DOES NOT MATTER* that PaX and ES "don't make sense" split out into 5 or 6 pieces. We merge in stuff *ALL THE TIME* in 20 or 30 chunks, where it doesn't make any real sense unless all 20 or 30 go in. Just today, there was a 29-patch monster replacing kexec, and another 12-patcher replacing something else. And I don't think anybody claims that many of those 29 patches stand totally by themselves. You install 25 of them, you probably don't have a working kexec, which is the goal of the patch series. The point is that *each* of those 29 patches is small and self-contained enough to review for breakage of current stuff, elegance of coding, and so on. Now let's look at grsecurity: % wc grsecurity-2.1.0-2.6.10-200501071049.patch 23539 89686 700414 grsecurity-2.1.0-2.6.10-200501071049.patch 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 single patch that big. 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 they merged? Because they showed up in 4-8K chunks. > Split-out portions of PaX (and of ES) don't make sense. ASLR can be > evaded pretty easily: inject code, read %efp, find the GOT, read > addresses. The NX protections can be evaded by using ret2libc. on x86, > you need emulation to make an NX bit or the NX protections are useless. > So every part prevents every other part from being pushed gently aside. Right. But if you *submit* them as "a chunk to add x86 emulation of an NX bit", "a chunk to add ASLR", "a chunk to add NX", "a chunk to do FOO with the vsyscall page", and so on, they might actually have a snowball's chance of being included. If nothing else, the fact they're posted as different patches means each can be used as the anchor for a thread discussing the merits of *that* patch. Adrian Bunk has been submitting patches for the last several weeks which probably total *well* over the size of the PAX patch. And since they show up as separate patches, the non-controversial ones can sail by, the ALSA crew can comment when he hits an ALSA module, the filesystem people can comment when he hits one of their files, and so on. pgpI8qK6vttmC.pgp Description: PGP signature
Re: thoughts on kernel security issues
-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. > > > the difference is not that big and only in tradeoffs. eg pax trades > virtual address space against protecting a rare occurance (eg where exec > shield wouldn't work because of a high executable mapping. That really > doesn't happen in normal programs) > PAGEEXEC uses the same method as Exec Shield, but falls back to kernel assisted MMU walking when that fails. This does not split the address space in half. Stop pretending SEGMEXEC is the only emulation PaX has. PaX also allows more finegrained administrative control. > >>On a final note, isn't PaX the only technology trying to apply NX >>protections to kernel space? > > > 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* > > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7rkfhDd4aOud5P8RAmvXAKCMADZGBVZx9UVRTfmVCoSBY9ODrgCfVK5s djLbjG/KmLx8QotWNAqr6Mc= =Tcjc -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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 technically naive management to justify cost, time, and policy implications. The people on the list who disagree may view the security information issue in a very different context. Basically you are saying that if i disagree, my view is irrelevant. What do you expect with this kind of start. What I am saying is what I said, no reinterpretation needed. Linus has not had the experience of being an administrator working where policies and resources are controlled by someone else. I think experience is valuable. Linus Torvalds wrote: Unfortunately reality doesn't agree with you. Many organizations have no other effective way to convince management of the need for a fix except newspaper articles and magazine articles. A sometimes that has to get to the horror story stage before action is possible. All those to lines to say one thing . Managing security requires social skills. And people who haven't been there would not appreciate the reality if I said it in one line. And let's not kid ourselves: the security firms may have resources that they put into it, but the worst-case schenario is actual criminal intent. People who really have resources to study security problems, and who have _no_ advantage of using vendor-sec at all. And in that case, vendor-sec is _REALLY_ a huge mistake. I think you are still missing the point, I don't care if a security firm reads mailing lists or tea leaves, does research or just knows where to find it, they are paid to do it and if they do it well and report the problems which apply to me and the source of the fixes they keep me from missing something and at the same time save me time. Even reading only good mailing lists and newsgroups it takes a lot of time to keep current, and you see a lot of stuff you don't need. Does this resume to : Again it means what it says, security services are cost effective. They control the resources used in providing security, because in some companies there simply aren't the human resources available to do a good job. I want my company to be in control. And nobody else please, because i do not trust them. Who would you want in this security board ? No hackers i believe they have no incentive to shut the *** up, they do not care about money or their buisness or who knows why. So you want : a/ everyboddy is wrong, we cannot understand, b/ crackers "are too lazy in many cases to read the high-level hacker boards" c/ "How can i have fix without ever having a hole ?". Close your eyes and believe, that s the only way to achieved absolute safety. I am not kidding, billions of people does this, it seems efficient (only few dies by accident). d/ the world is mad , nobody cares about security except who we are in charge (and have no power in the politics). e/ i don t care who does the job but i want my god damn system to have no holes. I don't know how you got to this list from what I posted... Sorry for this rude analysis . I assume you want : 1/ a way to be alerted of the security hole of your application stack , and those only. 2/ fix before the script kiddies. And that is a reasonable summary of the goals. For one the fix is quite easy, it is a matter of getting security alerts in an easy way (maybe newsletter are getting old, what about a web as amazon does for stuff) and a filter on your application stack. I actually like newsletter and Email alerts, they can be set to generate interrupts at the level appropriate, from "you have mail" to pager alerts, as desired. For two, nobody can help. Script kiddies does not even read tech lists. They do not make the scripts. Those who made them usually don't just read ML, they read source, even binaries. And those who make a living of cracking usually do not tell anybody. No CERT alert. The only hope is easy to read code, audit. I don't regard any solution less that perfect as "nobody can help." Timely fixes significantly reduce the exposure, the world isn't perfect. As my wife says, "Life's a bitch. Then you die." -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - 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: thoughts on kernel security issues
> 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 address space against protecting a rare occurance (eg where exec shield wouldn't work because of a high executable mapping. That really doesn't happen in normal programs) > On a final note, isn't PaX the only technology trying to apply NX > protections to kernel space? 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). - 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: thoughts on kernel security issues
-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 emulation patch based on the plex86 announcement to >>a full featured security system, and is written by a competant security >>developer rather than a competant scheduler developer. > > > I would call that an insult to Ingo. > You're reading too deeply then. > > >>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 combinations of each protection can protect the others from being exploited and create a truly secure environment. Ingo said there's other stuff in ES that this doesn't apply to but *shrug* again, beyond what I intended when I said that. > >>ASLR can be >>evaded pretty easily: inject code, read %efp, find the GOT, read >>addresses. The NX protections can be evaded by using ret2libc. on x86, >>you need emulation to make an NX bit or the NX protections are useless. > > > actually modern x86 cpus have hardware NX. not my point. . . > > >>PT_GNU_STACK annoys me :P I'm more interested in 1) PaX' full set of >>markings (-ps for NX, -m for mprotect(), r for randmmap, x for >>randexec), 2) getting rid of the need for anything but -m, and 3) >>eliminating relocations. Sometimes they don't patch GLIBC here and >>Firefox won't load flash or Java because they're PT_GNU_STACK and don't >>really need it (the java executables are marked, but the java plug-in >>doesn't need PT_GNU_STACK). > > > so remark them. Manually. Annoying because now I'm doing PaX AND Exec Shield markings, but I do remark them anyway. This wasn't meant to sound like it was a major problem, just to be a side comment. > > >>I guess it works on Exec Shield, but it frightens me that I have to >>audit every library an executable uses for a PT_GNU_STACK marking to see >>if it has an executable stack. > > > there is lsexec which does this automatic for you based on running > propcesses > I don't want to run something potentially dangerous. Think secret military installation with no name and blank checks made out to nobody. The security has to scale up and down; it has to be useful for the home user, for the business, and for those that don't officially exist. > >>Either or if it stops an exploit; there's no "stopping an exploit >>better," just stopping more of them and having fewer loopholes. As I >>understand, ES' NX approximation fails if you relieve protections on a >>higher mapping > > > which is REALLY rare for programs to do > True, but PaX has a failsafe in PAGEEXEC, and doesn't suffer this in SEGMEXEC. > >>-- which confuses me, isn't vsyscall() a high-address >>executable mapping, which would disable NX protection for the full >>address space? > > > just like PaX, execshield has to disable the vsyscall page. > Exec-Shield actually has the code to 1) move the vsyscall page down in > the address space and 2) randomize it per process, but that is inactive > right now since it needs a bit of help from the VM that isn't provided > anymore since 2.6.8 or so. > > ah. > >>PaX though gives me powerful, flexible administrative control over >>executable space protections as a privileged resource. >>mprotect(PROT_EXEC|PROT_WRITE) isn't something normal programs need; so >>it's not something I allow everyone to do. > > > it's a balance between compatibility and security. PaX strikes a > somewhat different balance from E-S. E-S goes a long way to avoid > breaking things that posix requires, even if they are silly and rare. > Apps don't DO PROT_EXEC|PROT_WRITE normally after all.. so this added > "protect" is to a point artifical. > > The actual threat this mitigates is that the app may be ret2libc'd to mprotect() (possible with unrandomized ET_EXEC?), but in reality a more complex attack can accomplish the same thing. I prefer it more as a speed bump to expose broken code to me or at least give me an idea of what to audit. If something HAS to mprotect() the stack, then I HAVE to make sure that program is audited, or I'm just being a dumbass and waiting to be infected with a cheap worm some scriptkiddie wrote using a build-your-own-virus program. > > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7qvthDd4aOud5P8RAhbVAJ9Jdxp/mKByxWChjM1bQMVZaIN4JACfaJ1I Rezv+g9BE7ezKwHB5UCvdnk= =EEu/ -END PGP SIGNATURE- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Mor
Re: thoughts on kernel security issues
-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 point it becomes pretty pointless to > discuss any technical details, dont you think? > I'm shoddy on ES details, but I was more remarking on the overlapping functions between PaX and ES. > >>PT_GNU_STACK annoys me :P I'm more interested in 1) PaX' full set of >>markings (-ps for NX, -m for mprotect(), r for randmmap, x for >>randexec), [...] >> >>I guess it works on Exec Shield, but it frightens me that I have to >>audit every library an executable uses for a PT_GNU_STACK marking to >>see if it has an executable stack. > > > here there are two misconceptions: > > 1) you claim that the manual setting of markings is better than the > _automatic_ setting of markings in Fedora. Manual setting is a support > and maintainance nightmare, there can be false positives and false > negatives as well. Also, manual setting of markings assumes code review > or 'does this application break' type of feedback - neither is as > reliable as automatic detection done by the compiler. PaX has trampoline detection/emulation. I think the toolchain spits out libraries with -E when there's one. It's not inherited from libraries to the executable though; but a quick hack to trace down everything from `ldd` or `readelf` and grab the -E would do the same thing without giving a fully executable stack. > > 2) you claim that you have to audit everything. You dont have to. It's > all automatic. _Fedora developers_ (not you) then check the markings and > reduce the number of executable stacks as much as possible. > And a distribution maintainer could do the same with PaX. Once it's done it's fairly low maintenance. I know because I've done it myself. I can determine minimal pax markings on a given binary in about 15 seconds in most cases. > >>[...] ES' NX approximation fails if you relieve protections on a >>higher mapping-- which confuses me, isn't vsyscall() a high-address >>executable mapping, which would disable NX protection for the full >>address space? > > > another misconception. Read the patch and you'll see how it's solved. > I've been told it maps vsyscall at a lower address, though didn't remember until after I hit send. Is this true? > >>Aside from that, I just trust the PaX developer more. He's already >>got a more developed product; he's a security developer instead of a >>scheduler developer; and he reads CPU manuals for breakfast. > > > this is your choice, and i respect it. Please show the same amount of > respect for the choice of others as well, without badmouthing anything > just because their choice is different from yours. > 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. My concerns are only with real security, and in that respect I feel that if I didn't stand up and assert my understandings on the matter that people may hurt themselves. I can't put a slave collar on people and use force feedback to control their minds, but I don't have to keep quiet either. It doesn't much matter at this point. If everything goes well, PaX should show up in a fairly popular distribution soon, so we'll get to finally see something added that this conversation lacks: a genuine large-scale demonstration of the deployment of PaX. ES has that already; but until I can see the excellence and the failings of PaX deployed with a target on the average user as well, I can't make assessments about which deploys better in what cases and why. On a final note, isn't PaX the only technology trying to apply NX protections to kernel space? Granted, most kernel exploits aren't RCE; but it's still a basic protection that should be in place. Wouldn't it be embarassing to say one day that RCE is so rare we don't need to waste effort on kernel-level W/X separation, then the next day see an RCE exploit? :P (do it murphy, do it! >:P) This is just a generic observation; as I said, RCE in kernel is rare enough to not be a major selling point, but it's still a consideration. > Ingo > - > 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/ > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7qhthDd4aOud5P8RAkjFAJ0YGEjbpNvu2DEr7DiRicuVcWUwawCdGXV2 /CMT3w5TL7KmnsOR
Re: thoughts on kernel security issues
> 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 security system, and is written by a competant security > developer rather than a competant scheduler developer. I would call that an insult to Ingo. > Split-out portions of PaX (and of ES) don't make sense. they do. Somewhat. > ASLR can be > evaded pretty easily: inject code, read %efp, find the GOT, read > addresses. The NX protections can be evaded by using ret2libc. on x86, > you need emulation to make an NX bit or the NX protections are useless. actually modern x86 cpus have hardware NX. > PT_GNU_STACK annoys me :P I'm more interested in 1) PaX' full set of > markings (-ps for NX, -m for mprotect(), r for randmmap, x for > randexec), 2) getting rid of the need for anything but -m, and 3) > eliminating relocations. Sometimes they don't patch GLIBC here and > Firefox won't load flash or Java because they're PT_GNU_STACK and don't > really need it (the java executables are marked, but the java plug-in > doesn't need PT_GNU_STACK). so remark them. > > I guess it works on Exec Shield, but it frightens me that I have to > audit every library an executable uses for a PT_GNU_STACK marking to see > if it has an executable stack. there is lsexec which does this automatic for you based on running propcesses > > Either or if it stops an exploit; there's no "stopping an exploit > better," just stopping more of them and having fewer loopholes. As I > understand, ES' NX approximation fails if you relieve protections on a > higher mapping which is REALLY rare for programs to do > -- which confuses me, isn't vsyscall() a high-address > executable mapping, which would disable NX protection for the full > address space? just like PaX, execshield has to disable the vsyscall page. Exec-Shield actually has the code to 1) move the vsyscall page down in the address space and 2) randomize it per process, but that is inactive right now since it needs a bit of help from the VM that isn't provided anymore since 2.6.8 or so. > PaX though gives me powerful, flexible administrative control over > executable space protections as a privileged resource. > mprotect(PROT_EXEC|PROT_WRITE) isn't something normal programs need; so > it's not something I allow everyone to do. it's a balance between compatibility and security. PaX strikes a somewhat different balance from E-S. E-S goes a long way to avoid breaking things that posix requires, even if they are silly and rare. Apps don't DO PROT_EXEC|PROT_WRITE normally after all.. so this added "protect" is to a point artifical. - 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: thoughts on kernel security issues
* 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? > PT_GNU_STACK annoys me :P I'm more interested in 1) PaX' full set of > markings (-ps for NX, -m for mprotect(), r for randmmap, x for > randexec), [...] > > I guess it works on Exec Shield, but it frightens me that I have to > audit every library an executable uses for a PT_GNU_STACK marking to > see if it has an executable stack. here there are two misconceptions: 1) you claim that the manual setting of markings is better than the _automatic_ setting of markings in Fedora. Manual setting is a support and maintainance nightmare, there can be false positives and false negatives as well. Also, manual setting of markings assumes code review or 'does this application break' type of feedback - neither is as reliable as automatic detection done by the compiler. 2) you claim that you have to audit everything. You dont have to. It's all automatic. _Fedora developers_ (not you) then check the markings and reduce the number of executable stacks as much as possible. > [...] ES' NX approximation fails if you relieve protections on a > higher mapping-- which confuses me, isn't vsyscall() a high-address > executable mapping, which would disable NX protection for the full > address space? another misconception. Read the patch and you'll see how it's solved. > Aside from that, I just trust the PaX developer more. He's already > got a more developed product; he's a security developer instead of a > scheduler developer; and he reads CPU manuals for breakfast. this is your choice, and i respect it. Please show the same amount of respect for the choice of others as well, without badmouthing anything just because their choice is different from yours. Ingo - 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: thoughts on kernel security issues
-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 have them; personally I believe PaX is a more >>mature technology, since it's 1) still actively developed, and 2) been >>around since late 2000. The rest of the community dissagrees with me >>of course, [...] > > > might this disagreement be based on the fact that exec-shield _is_ being > actively developed and is in active use in Fedora/RHEL, and that split > out portions of exec-shield (e.g. flexmmap, PT_GNU_STACK, NX) are > already in the upstream kernel? > 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 security system, and is written by a competant security developer rather than a competant scheduler developer. Split-out portions of PaX (and of ES) don't make sense. ASLR can be evaded pretty easily: inject code, read %efp, find the GOT, read addresses. The NX protections can be evaded by using ret2libc. on x86, you need emulation to make an NX bit or the NX protections are useless. So every part prevents every other part from being pushed gently aside. PT_GNU_STACK annoys me :P I'm more interested in 1) PaX' full set of markings (-ps for NX, -m for mprotect(), r for randmmap, x for randexec), 2) getting rid of the need for anything but -m, and 3) eliminating relocations. Sometimes they don't patch GLIBC here and Firefox won't load flash or Java because they're PT_GNU_STACK and don't really need it (the java executables are marked, but the java plug-in doesn't need PT_GNU_STACK). I guess it works on Exec Shield, but it frightens me that I have to audit every library an executable uses for a PT_GNU_STACK marking to see if it has an executable stack. > (but no doubt PaX is fine and protects against exploits at least as > effectively as (and in some cases more effectively than) exec-shield, so > you've definitely not made a bad choice.) > Either or if it stops an exploit; there's no "stopping an exploit better," just stopping more of them and having fewer loopholes. As I understand, ES' NX approximation fails if you relieve protections on a higher mapping-- which confuses me, isn't vsyscall() a high-address executable mapping, which would disable NX protection for the full address space? PaX disables vsyscall when using PAGEEXEC on x86 because (since 2.6.6 or so) pipacs uses the same method as ExecShield as a best-effort, falling back to kernel-assisted MMU walking if that fails. Wasted effort with vsyscall. PaX though gives me powerful, flexible administrative control over executable space protections as a privileged resource. mprotect(PROT_EXEC|PROT_WRITE) isn't something normal programs need; so it's not something I allow everyone to do. Aside from that, I just trust the PaX developer more. He's already got a more developed product; he's a security developer instead of a scheduler developer; and he reads CPU manuals for breakfast. I think a lot of PaX is developed without real hardware-- I know he at least doesn't have an AMD64 (which is what I use PaX on-- and yes I use the regression tests), and he does a fine job anyway. This indicates to me that this is a serious project with someone who knows what he's doing, so I trust it more. > Ingo > - -- All content of all messages exchanged herein are left in the Public Domain, unless otherwise explicitly stated. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFB7pbmhDd4aOud5P8RAuV2AJ44dE9gvqZ9xwfENaWA6Hm81ALcfQCaA7mk QFZejeyBBLd1sdtSj3o4Avk= =hNuJ -END PGP SIGNATURE- - 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: thoughts on kernel security issues
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, you can only execute binaries that you cannot > write to, and that you cannot _get_ write permission to (ie you can't be > the owner of them either - possibly only binaries where the owner is > root). Well, if there's gdb installed on such machine, you can probably circumvent this. Hmm, you can probably do /lib/ld-linux.so.2 your binary, no? Pavel -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - 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: thoughts on kernel security issues
* 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's 1) still actively developed, and 2) been > around since late 2000. The rest of the community dissagrees with me > of course, [...] might this disagreement be based on the fact that exec-shield _is_ being actively developed and is in active use in Fedora/RHEL, and that split out portions of exec-shield (e.g. flexmmap, PT_GNU_STACK, NX) are already in the upstream kernel? (but no doubt PaX is fine and protects against exploits at least as effectively as (and in some cases more effectively than) exec-shield, so you've definitely not made a bad choice.) Ingo - 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: thoughts on kernel security issues
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 technically naive management to > justify cost, time, and policy implications. The people on the list who > disagree may view the security information issue in a very different > context. Basically you are saying that if i disagree, my view is irrelevant. What do you expect with this kind of start. > Linus Torvalds wrote: > > > What vendor-sec does is to make it "socially acceptable" to be a parasite. > > > > I personally think that such behaviour simply should not be encouraged. If > > you have a security "researcher" that has some reason to delay his > > disclosure, you should see for for what he is: looking for cheap PR. You > > shouldn't make excuses for it. Any research organization that sees PR as a > > primary objective is just misguided. > > There are damn fine reasons for not having immediate public disclosure, > it allows vandors and administrators to close the hole before the script > kiddies get a hold of it. And they are the real problem, because there > are so MANY of them, and they tend to do slash and burn stuff, wipe out > your files, steal your identity, and other things you have to notice. > They aren't smart enough to find holes themselves in most cases, they > are too lazy in many cases to read the high-level hacker boards, and a > few weeks of delay in many cases lets the careful avoid damage. > > Security through obscurity doesn't work, but a small delay for a fix to > be developed can prevent a lot of problems. And of course the > information should be released, it encourages the creation and > installation of fixes. > > Oh, and many of the problem reports result in "cheap PR" consisting of a > single line mention in a CERT report or similar. Most people are not > doing it for the glory. Nobody told against a small delay , in most of the case that is already what is happening today. There is a little problem in this rhetoric. You want fix fast and disclosure latter. As soon as the fix (we are talking about source available) is out, the hole is too. Wondering if chiken or egg is great flame subject. > > > What's the alternative? I'd like to foster a culture of > > > > (a) accepting that bugs happen, and that they aren't news, but making > > sure that the very openness of the process means that people know > > what's going on exactly because it is _open_, not because some news > > organization had to make a big stink about it just to make a vendor > > take notice. > > Linux vendors aside, many vendors react in direct proportion to the bad > publicity engendered. I'd like the world to work that way, but in many > places it doesn't. > > > > Right now, people seem to think that big news media warnings on > > cnet.com about SP2 fixing 15 vulnerabilities or similar is the proper > > way to get people to upgrade. That just -cannot- be right. > > Unfortunately reality doesn't agree with you. Many organizations have no > other effective way to convince management of the need for a fix except > newspaper articles and magazine articles. A sometimes that has to get to > the horror story stage before action is possible. All those to lines to say one thing . Managing security requires social skills. > > And let's not kid ourselves: the security firms may have resources that > > they put into it, but the worst-case schenario is actual criminal intent. > > People who really have resources to study security problems, and who have > > _no_ advantage of using vendor-sec at all. And in that case, vendor-sec is > > _REALLY_ a huge mistake. > > I think you are still missing the point, I don't care if a security firm > reads mailing lists or tea leaves, does research or just knows where to > find it, they are paid to do it and if they do it well and report the > problems which apply to me and the source of the fixes they keep me from > missing something and at the same time save me time. Even reading only > good mailing lists and newsgroups it takes a lot of time to keep > current, and you see a lot of stuff you don't need. > Does this resume to : I want my company to be in control. And nobody else please, because i do not trust them. Who would you want in this security board ? No hackers i believe they have no incentive to shut the *** up, they do not care about money or their buisness or who knows why. So you want : a/ everyboddy is wrong, we cannot understand, b/ crackers "are too lazy in many cases to read the high-level hacker boards" c/ "How can i have fix without ever having a hole ?". Close your eyes and believe, that s the only way to achieved absolute safety. I am not kidding, billions of people does this, it seems effi
Re: thoughts on kernel security issues
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, and policy implications. The people on the list who disagree may view the security information issue in a very different context. Linus Torvalds wrote: What vendor-sec does is to make it "socially acceptable" to be a parasite. I personally think that such behaviour simply should not be encouraged. If you have a security "researcher" that has some reason to delay his disclosure, you should see for for what he is: looking for cheap PR. You shouldn't make excuses for it. Any research organization that sees PR as a primary objective is just misguided. There are damn fine reasons for not having immediate public disclosure, it allows vandors and administrators to close the hole before the script kiddies get a hold of it. And they are the real problem, because there are so MANY of them, and they tend to do slash and burn stuff, wipe out your files, steal your identity, and other things you have to notice. They aren't smart enough to find holes themselves in most cases, they are too lazy in many cases to read the high-level hacker boards, and a few weeks of delay in many cases lets the careful avoid damage. Security through obscurity doesn't work, but a small delay for a fix to be developed can prevent a lot of problems. And of course the information should be released, it encourages the creation and installation of fixes. Oh, and many of the problem reports result in "cheap PR" consisting of a single line mention in a CERT report or similar. Most people are not doing it for the glory. What's the alternative? I'd like to foster a culture of (a) accepting that bugs happen, and that they aren't news, but making sure that the very openness of the process means that people know what's going on exactly because it is _open_, not because some news organization had to make a big stink about it just to make a vendor take notice. Linux vendors aside, many vendors react in direct proportion to the bad publicity engendered. I'd like the world to work that way, but in many places it doesn't. Right now, people seem to think that big news media warnings on cnet.com about SP2 fixing 15 vulnerabilities or similar is the proper way to get people to upgrade. That just -cannot- be right. Unfortunately reality doesn't agree with you. Many organizations have no other effective way to convince management of the need for a fix except newspaper articles and magazine articles. A sometimes that has to get to the horror story stage before action is possible. And let's not kid ourselves: the security firms may have resources that they put into it, but the worst-case schenario is actual criminal intent. People who really have resources to study security problems, and who have _no_ advantage of using vendor-sec at all. And in that case, vendor-sec is _REALLY_ a huge mistake. I think you are still missing the point, I don't care if a security firm reads mailing lists or tea leaves, does research or just knows where to find it, they are paid to do it and if they do it well and report the problems which apply to me and the source of the fixes they keep me from missing something and at the same time save me time. Even reading only good mailing lists and newsgroups it takes a lot of time to keep current, and you see a lot of stuff you don't need. -- -bill davidsen ([EMAIL PROTECTED]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - 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/
