| |||||||||||||
On the security of our processes and infrastructureOn the security of our processes and infrastructurePosted Sep 9, 2011 14:50 UTC (Fri) by malor (subscriber, #2973)Parent article: On the security of our processes and infrastructure
This isn't about script kiddies anymore; it hasn't been for a while now. The compromise of kernel.org needs to be seen as part of a wider pattern of attacks on high-profile sites - Google, DigiNotar, RSA Security, etc. I wonder if this will do anything to convince the kernel devs that the security community is not just theater? Their determined insistence on hiding security fixes is probably going to end up causing people's deaths. It would be particularly notable if the kernel.org compromise was from a security fix that wasn't rolled out because it wasn't correctly labeled.
(Log in to post comments)
On the security of our processes and infrastructure Posted Sep 13, 2011 11:29 UTC (Tue) by mpr22 (subscriber, #60784) [Link] My impression is that the kernel devs' position is approximately "if you rely on a magic flag to tell you whether a given fix is a security fix, you have a security problem and you should investigate it".
On the security of our processes and infrastructure Posted Sep 15, 2011 16:39 UTC (Thu) by slashdot (guest, #22014) [Link]
You are just supposed to "roll out" ALL fixes.
On the security of our processes and infrastructure Posted Sep 17, 2011 4:28 UTC (Sat) by malor (subscriber, #2973) [Link]
Which means you inevitably must also accept a bunch of new features that haven't been completely thought out or tested, resulting in yet more patches resulting in yet more untested features resulting in yet more patches. It's a never-ending stream of 'which insecurity do I have this week?'
At this point, if I had data that would threaten my livelihood or life if it leaked, I would never, never not EVER put it on a Linux box.
On the security of our processes and infrastructure Posted Sep 17, 2011 20:00 UTC (Sat) by jrn (subscriber, #64214) [Link]
> Which means you inevitably must also accept a bunch of new features
Have you looked at a linux-stable (i.e., 3.x.y) kernel recently?
On the security of our processes and infrastructure Posted Sep 19, 2011 12:31 UTC (Mon) by mpr22 (subscriber, #60784) [Link] I certainly know that at this point, if I were the maintainer of an OS kernel I would flag all fixes to the kernel as security fixes, simply because (a) selectively flagging fixes is subject to human error (b) there are too many people out there who can't be trusted to know the difference between "A implies B" and "not-A implies not-B". (In this case, A is "the fix is flagged as a security fix" and B is "omitting the fix has negative implications for the security of the system".) Out of interest, what OS would you trust to keep such information safe? (For my part, I think the right solution there is to keep the information strongly encrypted, and never let the keys reside - even in volatile storage - on a network-connected device.)
|
|||||||||||||