Hey, all. The topic of whether and which security issues should block releases has come up several times before. While we haven't actually had many really serious security issues to worry about since the introduction of the current release criteria system, I think it's certainly something we should take into account. At the same time, it's fairly established in practice that we don't just consider anything worth issuing a CVE for as a release-blocking bug. So, to capture what I believe would be the intent of the project, I propose this as an Alpha release criterion for F16 onwards. (For those on devel and security lists who may not be completely familiar with the release criteria / blocker system, this would mean that any bug for an issue which breached the criterion should be considered a release blocker for any Alpha, Beta or Final release).
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
Points to consider:
* Possible variants to the type of vulnerability covered...do we also want to make local privesc vulns blocking? Conversely, do we want to make only remote *root* execution vulns blocking? I don't know if anyone would want to go as far as making DoS vulns release blocking, but speak up if you would! (Of course there is again the local/remote distinction to consider there: 'all DoS vulns' would be a much tighter standard than 'remote DoS vulns').
* The caveat about where the issue is exploitable is important because if you can't exploit it from the installer or a live image, it becomes less relevant whether we ship with it or not, because you would be safe with the first post-install update assuming we submitted an update for the issue promptly. But it may be the case that we want to broaden it out to also cover issues that can be exploited from a default DVD install, if we consider the window between install and first update (if updates repos aren't used during installation) to be unacceptable.
* We have a system whereby the criteria get more onerous from Alpha to Beta to Final, so it could be the case that we accept worse security issues in Alpha than in Beta and so on; we could have a loose criterion for Alpha and a tighter one for Beta. In this case it felt sensible to me to just go with one criterion, but please say if you disagree.
* The aim of the release criteria is more to codify existing practice than to extend it; we have taken security issues as release blockers before and considered but rejected less serious ones, but we have done so on an ad hoc basis. I tried to write the criterion to reflect our past practice on this. So precedents are important here; if you have any that contradict the proposed criterion, please do cite them.
Feedback please! Thanks :)
On Wed, 2011-05-18 at 08:57 -0700, Adam Williamson wrote:
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
Points to consider:
One more 'point to consider' that I forgot: for most things we only consider the 'desktop' and KDE live images as capable of blocking the release, but I thought for security issues it makes sense to broaden this out to all the images we actually ship as part of the release. This is definitely up for debate, though; it would be possible to tighten it down to only desktop and KDE, or to only the most commonly-used spins, or something.
On 05/18/2011 03:57 PM, Adam Williamson wrote:
Feedback please! Thanks:)
Given that we ship selinux on by default should this proposal only be applicable to exploits/vulnerability that selinux cant catch and prevent which leaves us with <insert type of exploits here )?
Don't we need individual(s) from the security team that will be doing actively security audit during the development cycle and reporting back to QA?
Would not applying this security release proposal to final only suffice?
JBG
On 05/18/2011 09:58 PM, "Jóhann B. Guðmundsson" wrote:
On 05/18/2011 03:57 PM, Adam Williamson wrote:
Feedback please! Thanks:)
Given that we ship selinux on by default should this proposal only be applicable to exploits/vulnerability that selinux cant catch and prevent which leaves us with <insert type of exploits here )?
No. SELInux (or firewall) is not a first line of defense. These get turned off by some users and we need to be sure we aren't relying on them solely. If there are important security issues, they should be fixed before release regardless of whether SELinux would mitigate them or not
Rahul
On Wed, May 18, 2011 at 10:27:07PM +0530, Rahul Sundaram wrote:
On 05/18/2011 09:58 PM, "Jóhann B. Guðmundsson" wrote:
On 05/18/2011 03:57 PM, Adam Williamson wrote:
Feedback please! Thanks:)
Given that we ship selinux on by default should this proposal only be applicable to exploits/vulnerability that selinux cant catch and prevent which leaves us with <insert type of exploits here )?
No. SELInux (or firewall) is not a first line of defense. These get turned off by some users and we need to be sure we aren't relying on them solely. If there are important security issues, they should be fixed before release regardless of whether SELinux would mitigate them or not
I have to disagree on this point, I think SELinux and the firewall are in fact valid vulnerability mitigation paths and since they are in fact enabled by default with the release then they should be able to satisfy the requirements for release criteria. I don't think we as a project can handle the long list of what users can and can't do once their system is installed, I personally think that in these release criteria we should focus on what is and isn't vulnerable from a default installation. If a user decides to turn of PackageKit, turn off the firewall, disable SELinux, and not manually pull package updates .... there's not much we can do for them. (And yes, I am aware this isn't the case you brought up but I'm simply trying to point out the slippery slope of "what if the user does X?" that we could get ourselves into that would make it difficult for us as a community to QA.
Just my opinion ... questions, comments, and snide remarks welcome as always :)
-AdamM
On 05/18/2011 05:18 PM, Adam Miller wrote:
On Wed, May 18, 2011 at 10:27:07PM +0530, Rahul Sundaram wrote:
On 05/18/2011 09:58 PM, "Jóhann B. Guðmundsson" wrote:
On 05/18/2011 03:57 PM, Adam Williamson wrote:
Feedback please! Thanks:)
Given that we ship selinux on by default should this proposal only be applicable to exploits/vulnerability that selinux cant catch and prevent which leaves us with<insert type of exploits here )?
No. SELInux (or firewall) is not a first line of defense. These get turned off by some users and we need to be sure we aren't relying on them solely. If there are important security issues, they should be fixed before release regardless of whether SELinux would mitigate them or not
I have to disagree on this point, I think SELinux and the firewall are in fact valid vulnerability mitigation paths and since they are in fact enabled by default with the release then they should be able to satisfy the requirements for release criteria. I don't think we as a project can handle the long list of what users can and can't do once their system is installed, I personally think that in these release criteria we should focus on what is and isn't vulnerable from a default installation. If a user decides to turn of PackageKit, turn off the firewall, disable SELinux, and not manually pull package updates .... there's not much we can do for them. (And yes, I am aware this isn't the case you brought up but I'm simply trying to point out the slippery slope of "what if the user does X?" that we could get ourselves into that would make it difficult for us as a community to QA.
That is my take on the scenario along with do we actually need any security release criteria surrounding the rest ( the issue that selinux does not catch ) as opposed to just ping the security team on case by case bases should the need arise and get them to assess the situation and then either flag the bug a blocker nth or a non blocker..
JBG
On Wed, 2011-05-18 at 16:28 +0000, "Jóhann B. Guðmundsson" wrote:
On 05/18/2011 03:57 PM, Adam Williamson wrote:
Feedback please! Thanks:)
Given that we ship selinux on by default should this proposal only be applicable to exploits/vulnerability that selinux cant catch and prevent which leaves us with <insert type of exploits here )?
I kinda considered that to be implicit in the criterion as written, but as two people have asked about it, obviously we should clarify that :)
Don't we need individual(s) from the security team that will be doing actively security audit during the development cycle and reporting back to QA?
Well, 'enforcing' the criteria is a separate issue from determining them, and we don't really need to discuss it here. Having an explicit criterion adds value even if we don't set up a formal validation system, because it gives us solid ground to review any security issues which get proposed as release blockers on an ad hoc basis.
Would not applying this security release proposal to final only suffice?
Well, I mean, it depends what you mean by 'suffice' :). I worked on the basis that we probably don't want to ship any widely-distributed 'release' with a major security issue, but as I wrote, it's certainly up for debate.
On Wed, May 18, 2011 at 08:57:17 -0700, Adam Williamson awilliam@redhat.com wrote:
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
Points to consider:
I think there may be some remote exploits that we wouldn't want to block for. For example if wesnoth turns out to be vulnerable to the game server or one of the other clients, I don't thank is something we'd want to block for. If firefox was vulnerable to web pages you visit being able to execute unsandboxed code, then I feel it's a close call.
I'd prefer not to limit remote code execution to just root. User data and network bandwidth are valuable. Then we also need to worry about local root exploits being used in combination with non-root remote code exploits.
I think it is also worth considering whether the exploits are really exploitable with our default configuration (selinux in enforcing mode).
On 5/18/11 11:57 AM, Adam Williamson wrote:
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
Seems reasonable at first glance.
One anecdotal experience: FC5 (wow) shipped with an X server that was vulnerable to a local root exploit: due to a bug, normal users could set the X server's module path, and the server would always load a certain module first, so you could just set an ELF constructor that called exec("/bin/sh") and win. The public commit to fix the issue was 20 March 2006, the exact day of the FC5 release, so I suspect we chose the embargo date on that basis.
Which, I think, was the right move.
The concern I would have with an explicit policy like this is the schedule effects. We would not be able to commit or build a package with the embargoed fix until after the embargo date. _Then_ we compose. Then we test (unless we think existing testing is sufficient). Then we push to mirrors. Then we make the release links public. That whole process is still on the order of a week I think, which is slightly longer than one would desire.
- ajax
Adam Williamson wrote:
Hey, all. The topic of whether and which security issues should block releases has come up several times before.
Indeed it has. The decision was always that it's not a good idea. I don't see how the situation has changed to warrant beating that dead horse again.
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release.
It's impossible to ship an exploit-free release just like it's impossible to ship a bug-free release.
We have a process for security fixes, it's called "updates". I don't see how a 0-day update wouldn't be an appropriate resolution for a security issue.
Now if you are talking about NTH, then yes, security fixes should be NTH. Maybe even all of them. But I don't think we should be blocking or delaying any release for them. We can't fix them all anyway.
Kevin Kofler
On Wed, 2011-05-18 at 19:22 +0200, Kevin Kofler wrote:
Adam Williamson wrote:
Hey, all. The topic of whether and which security issues should block releases has come up several times before.
Indeed it has. The decision was always that it's not a good idea. I don't see how the situation has changed to warrant beating that dead horse again.
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release.
That's certainly a valid concern; does anyone have hard data on this? Either way, it's certainly worth considering that we can do nothing about issues that come to light after release, in relation to the installer and live image.
We have a process for security fixes, it's called "updates". I don't see how a 0-day update wouldn't be an appropriate resolution for a security issue.
Now if you are talking about NTH, then yes, security fixes should be NTH. Maybe even all of them. But I don't think we should be blocking or delaying any release for them. We can't fix them all anyway.
No, this would be release blocker stuff, not NTH. But I'm floating a balloon here; if most agree with you, we could consider adding security issues to the NTH principles instead.
On 5/18/11 1:22 PM, Kevin Kofler wrote:
Adam Williamson wrote:
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release.
The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too.
We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible.
Also: twelve month.
- ajax
On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote:
On 5/18/11 1:22 PM, Kevin Kofler wrote:
Adam Williamson wrote:
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release.
The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too.
We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible.
Also: twelve month.
Well, I think his point is that it's almost certain that some 'unknown' exposures will become 'known' during the life cycle of a release, at which point the live images we release three months previously are vulnerable to a known security exploit and there's exactly nothing we can do about it - so worrying about the ones we _can_ fix at release time becomes less important, when viewed from that perspective. It's a good point.
On Wed, May 18, 2011 at 10:44:16AM -0700, Adam Williamson wrote:
Well, I think his point is that it's almost certain that some 'unknown' exposures will become 'known' during the life cycle of a release, at which point the live images we release three months previously are vulnerable to a known security exploit and there's exactly nothing we can do about it
Yes.
so worrying about the ones we _can_ fix at release time becomes less important, when viewed from that perspective.
No.
Shipping a safe product is a goal that ethically demands our best effort, even if we'll never be totally successful. Not being able to get them all makes the ones we can get more important, not less.
--CJD
On 5/18/11 1:44 PM, Adam Williamson wrote:
On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote:
On 5/18/11 1:22 PM, Kevin Kofler wrote:
Adam Williamson wrote:
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release.
The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too.
We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible.
Also: twelve month.
Well, I think his point is that it's almost certain that some 'unknown' exposures will become 'known' during the life cycle of a release, at which point the live images we release three months previously are vulnerable to a known security exploit and there's exactly nothing we can do about it - so worrying about the ones we _can_ fix at release time becomes less important, when viewed from that perspective. It's a good point.
It's a rationally argued position, but argued from an initial state that does not reflect reality.
I mean, the conclusion from that line of reasoning is that all releases are futile: any sufficiently severe bug unknown at release time could be discovered later, and could be so crippling as to make the release useless.
I don't necessarily disagree with that logic either. However, we've decided to do releases. Therefore we ought to have some standard of quality for release content definition. After that it's all a matter of drawing the line. I'd argue that knowingly exposing the user to a remote root exploit is actively negligent behaviour; remote user code execution, less so but still very bad; local privilege escalation, less so still.
I'd rather not ship something that I _know_ will result in the user getting rooted. This is so fundamental a tenet of quality that I have difficulty even believing someone could disagree. I guess Kevin's brain is simply something I should stop being surprised by.
- ajax
On Wed, 2011-05-18 at 14:02 -0400, Adam Jackson wrote:
On 5/18/11 1:44 PM, Adam Williamson wrote:
On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote:
On 5/18/11 1:22 PM, Kevin Kofler wrote:
Adam Williamson wrote:
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release.
The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too.
We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible.
Also: twelve month.
Well, I think his point is that it's almost certain that some 'unknown' exposures will become 'known' during the life cycle of a release, at which point the live images we release three months previously are vulnerable to a known security exploit and there's exactly nothing we can do about it - so worrying about the ones we _can_ fix at release time becomes less important, when viewed from that perspective. It's a good point.
It's a rationally argued position, but argued from an initial state that does not reflect reality.
I mean, the conclusion from that line of reasoning is that all releases are futile: any sufficiently severe bug unknown at release time could be discovered later, and could be so crippling as to make the release useless.
I don't necessarily disagree with that logic either. However, we've decided to do releases. Therefore we ought to have some standard of quality for release content definition. After that it's all a matter of drawing the line. I'd argue that knowingly exposing the user to a remote root exploit is actively negligent behaviour; remote user code execution, less so but still very bad; local privilege escalation, less so still.
I'd rather not ship something that I _know_ will result in the user getting rooted. This is so fundamental a tenet of quality that I have difficulty even believing someone could disagree. I guess Kevin's brain is simply something I should stop being surprised by.
Also note that targeting the heaps of poor users that are eager to try the newly shipped Fedora release would be probably much more easy and efficient than targeting one user installing the Fedora here or there a few months later. So yes, definitely remote root and user exploits in the installer, Live CDs, and in my opinion also the default install should be release blockers.
By the way do we have statistics about when this kind of blockers happened during our previous releases?
Tomas Mraz wrote:
Also note that targeting the heaps of poor users that are eager to try the newly shipped Fedora release would be probably much more easy and efficient than targeting one user installing the Fedora here or there a few months later.
Huh? The "heaps" of users do not install Fedora the day of the release. Only very few very enthousiastic and very impatient early adopters do that (and I blame them for needlessly swamping our mirrors). Actual users, especially those most likely to try out and install from live images (as opposed to e.g. upgrading an existing release using preupgrade, which pulls in updates automatically), install Fedora whenever they discover it, which can be at any time of our release cycle.
For example, we gave out a few dozen Fedora 14 live media less than 2 weeks ago at Linuxwochen Wien!
And for several practical reasons I don't want to go into here, the media we handed out at the event were all GA images, not respins. Users downloading the images themselves will probably also opt for the GA ISOs we officially distribute, not unofficial respins we do not officially endorse.
Kevin Kofler
Kevin Kofler wrote:
The "heaps" of users do not install Fedora the day of the release. Only very few very enthousiastic and very impatient early adopters do that (and I blame them for needlessly swamping our mirrors).
If they are so very few, how can they swamp a couple hundred big FTP archives with a collective bandwidth of a few hundred gigabits per second?
Björn Persson
Adam Jackson wrote:
It's a rationally argued position, but argued from an initial state that does not reflect reality.
I mean, the conclusion from that line of reasoning is that all releases are futile: any sufficiently severe bug unknown at release time could be discovered later, and could be so crippling as to make the release useless.
I don't necessarily disagree with that logic either. However, we've decided to do releases. Therefore we ought to have some standard of quality for release content definition. After that it's all a matter of drawing the line. I'd argue that knowingly exposing the user to a remote root exploit is actively negligent behaviour; remote user code execution, less so but still very bad; local privilege escalation, less so still.
The thing is, if we block the release for each and every known security issue, considering the time passing between notification and public availability of a fix, we will never be able to release anything. We have to draw the line somewhere, and the best way to do it is to use our time-based schedule.
We have done 15 releases successfully that way, what's the reason for changing this approach now? And how can this not lead to a chain of slippage where each slippage for a security fix causes several new security fixes to pop up, for which we slip again, ad infinitum?
We cannot fix all security issues any more that we can fix all bugs. We have to get SOMETHING out at some point.
I'd rather not ship something that I _know_ will result in the user getting rooted. This is so fundamental a tenet of quality that I have difficulty even believing someone could disagree. I guess Kevin's brain is simply something I should stop being surprised by.
You don't KNOW that it will get the user rooted. Now if the hole is in a service listening to the Internet by default and is getting exploited by an automated worm, you can reasonably say that it WILL get the user rooted, but if it's e.g. a browser vulnerability, it will only hit the users if and when they access an infected or malicious site. Hopefully they'll have installed our 0-day security fix by then! (I'd hope sites like start.fedoraproject.org will not carry some trojan horse!)
And your logic is flawed in that you assume that every user installs Fedora the day of the release. That's actually very far from the truth. All your efforts to release without known security vulnerabilities are for naught when the next one inevitably comes up soon after the release and there won't be a fixed set of live images for 6 months.
Kevin Kofler
On 5/18/11 4:49 PM, Kevin Kofler wrote:
The thing is, if we block the release for each and every known security issue, considering the time passing between notification and public availability of a fix, we will never be able to release anything. We have to draw the line somewhere, and the best way to do it is to use our time-based schedule.
False induction.
I'd rather not ship something that I _know_ will result in the user getting rooted. This is so fundamental a tenet of quality that I have difficulty even believing someone could disagree. I guess Kevin's brain is simply something I should stop being surprised by.
You don't KNOW that it will get the user rooted. Now if the hole is in a service listening to the Internet by default and is getting exploited by an automated worm, you can reasonably say that it WILL get the user rooted, but if it's e.g. a browser vulnerability, it will only hit the users if and when they access an infected or malicious site. Hopefully they'll have installed our 0-day security fix by then! (I'd hope sites like start.fedoraproject.org will not carry some trojan horse!)
Now you're drawing lines. Before you were saying "this is impossible, we shouldn't try". Moving the goalposts.
I'm done arguing with you on this, it's clear you don't know how.
- ajax
Adam Jackson wrote:
On 5/18/11 4:49 PM, Kevin Kofler wrote:
The thing is, if we block the release for each and every known security issue, considering the time passing between notification and public availability of a fix, we will never be able to release anything. We have to draw the line somewhere, and the best way to do it is to use our time-based schedule.
False induction.
Uh no, you can't dismiss my argument that easily…
If, say, it takes 2 weeks to get a fix for a critical security issue published/publishable (i.e. developed and put out of embargo), and if there's at least 1 critical security vulnerability in every 2-week interval, we will mathematically never be able to release if we treat all critical security vulnerabilities as blockers. (And that sentence remains true no matter how you define "critical".) And this is just one of the possible constellations, and a very simplified one to prove my point. In practice, things are much more stochastic, but there are many possible scenarios in which each slippage will cause another.
You show no evidence whatsoever showing that this is not going to happen. So this means you MUST consider the scenario I pointed out at least as a worst- case scenario. (Empirically, I'd actually expect it to be the average-case scenario, but I'll admit I have no statistical evidence to support that.)
Now you're drawing lines. Before you were saying "this is impossible, we shouldn't try". Moving the goalposts.
Call me when you see a security issue which actually fits my description (i.e. an automated worm which successfully exploits a service that's enabled by default, listening to more than just localhost by default and not firewalled by default), and that during the short release candidate time window, even. I haven't seen it happen in any of the 14 releases we did nor the 15th we're doing now, and I don't see it happening any time soon. This is purely theoretical.
Now I won't object to putting this exact item on the blocker list, but I don't expect it to get invoked, ever. I DO object to putting anything security-related OTHER than that up as a blocker, because we need to release at some point.
Kevin Kofler
On Wed, 2011-05-18 at 22:49 +0200, Kevin Kofler wrote:
The thing is, if we block the release for each and every known security issue, considering the time passing between notification and public availability of a fix, we will never be able to release anything. We have to draw the line somewhere, and the best way to do it is to use our time-based schedule.
I think this overstates the case. The proposed criterion intentionally does not foresee blocking for 'each and every known security issue', and no-one so far has advocated doing such a thing; the idea that we should block only for particularly serious issues seems reasonably well accepted. Particularly serious issues really don't come up that often; I'm not aware of any such issue which would have resulted in any delay to the F15 Alpha, Beta or Final releases, for instance. I don't believe F15 Final (RC3) is subject to any known remote code-execution vulnerability.
We have done 15 releases successfully that way, what's the reason for changing this approach now?
As I said, the idea isn't really to change anything; the idea is to codify our current approach. As my initial mail said, we have treated security issues as blockers in the past, but with no solid base of policy to justify it, it was done on a case-by-case, ad hoc basis. The idea of the release criteria is to provide a solid base for making consistent decisions when it comes to release blockers (based as far as possible on existing practice), as opposed to the old system of trying to follow previous precedent more or less from memory, and beyond that, going with whatever felt right. I think the release criteria / release blocker system has proven itself pretty well over the last few releases.
And how can this not lead to a chain of slippage where each slippage for a security fix causes several new security fixes to pop up, for which we slip again, ad infinitum?
In theory it could, sure. In practice I think an analysis of the frequency of remote code execution exploits would show it's not likely to happen very often, but of course it would be best to check this for sure.
On Wed, 2011-05-18 at 10:44 -0700, Adam Williamson wrote:
On Wed, 2011-05-18 at 13:37 -0400, Adam Jackson wrote:
On 5/18/11 1:22 PM, Kevin Kofler wrote:
Adam Williamson wrote:
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
This is just completely and utterly moot considering that there are going to be many more unknown vulnerabilities than known ones, and that several of those are inevitably going to come up during the 6-month lifetime of a release.
The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too.
We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible.
Also: twelve month.
Well, I think his point is that it's almost certain that some 'unknown' exposures will become 'known' during the life cycle of a release, at which point the live images we release three months previously are vulnerable to a known security exploit and there's exactly nothing we can do about it - so worrying about the ones we _can_ fix at release time becomes less important, when viewed from that perspective. It's a good point.
Is it unthinkable to respin the images with those fixes ? Usually the patches are quite simple to backport, and we are talking about a limited set of bugs (remote root exploit on install) after all.
Simo.
On Wed, 2011-05-18 at 14:40 -0400, Simo Sorce wrote:
Is it unthinkable to respin the images with those fixes ? Usually the patches are quite simple to backport, and we are talking about a limited set of bugs (remote root exploit on install) after all.
Unthinkable, no, but there are various practical issues with doing official re-spins which have meant it's never actually happened, and the project for doing it semi-externally - Unity - is often way behind. One that I wasn't previously aware of, which Spot explained to me recently, is U.S. export regulations; we have to go through a long and tedious regulatory process for official builds, and no-one's particularly keen to start doing that multiple times per cycle for respins.
Few questions here:
What does this scope include? Is it merely the LiveCD for GNOME and KDE? Does it also include the DVD install selections for both of these packages? (They are different)
What about clearly vulnerable areas, like "Web Sever" that is push-button selectable on install?
Do we make a list of what is installed in these situations and create a watch-list like “crit-path”?
IMHO, Local and remote privilege escalation issues with the default configurations should block the release if they are known prior to making the release. My only questions are scope definitions that would clarify exactly what packages we are talking about here.
Earlier, someone kindly wrote a STIG script to analyze an installed system. Fixing these permission defaults would go a ways to mitigating issues.
Poly-instantiated-tmpdirs would also be NTH by default. Confined users by default would also be an awesome plan. (I can go on, but the big plan is to have a "secure by default" install, and let the users define where they want to open access up. Anything the user does after firstboot should really not be covered here.)
We have to define a clear scope before a decent decision.
-dj
On Wed, May 18, 2011 at 1:51 PM, Adam Williamson awilliam@redhat.comwrote:
On Wed, 2011-05-18 at 14:40 -0400, Simo Sorce wrote:
Is it unthinkable to respin the images with those fixes ? Usually the patches are quite simple to backport, and we are talking about a limited set of bugs (remote root exploit on install) after all.
Unthinkable, no, but there are various practical issues with doing official re-spins which have meant it's never actually happened, and the project for doing it semi-externally - Unity - is often way behind. One that I wasn't previously aware of, which Spot explained to me recently, is U.S. export regulations; we have to go through a long and tedious regulatory process for official builds, and no-one's particularly keen to start doing that multiple times per cycle for respins. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
On Wed, 2011-05-18 at 15:43 -0500, dr johnson wrote:
Few questions here:
What does this scope include? Is it merely the LiveCD for GNOME and KDE? Does it also include the DVD install selections for both of these packages? (They are different)
Well, that's part of the discussion I wanted to start. As written it covers anything that actually runs as part of the installation sequence on the DVD and anything you can run directly from within one of the published live images, it's less concerned with post-install scenarios.
Do we make a list of what is installed in these situations and create a watch-list like “crit-path”?
As I wrote in a previous reply, implementation of planned testing and validation for criteria is a rather different topic from definition of the criteria, and it's probably best to discuss them separately.
Simo Sorce wrote:
Is it unthinkable to respin the images with those fixes ? Usually the patches are quite simple to backport, and we are talking about a limited set of bugs (remote root exploit on install) after all.
Then we'd need a second (or third, if the Features repo finally happens) update channel with only GA + backported security fixes. Do you volunteer to maintain that? And what about the required resources, e.g. the extra Koji build target? And this does not even address spinning and distributing the respun images themselves.
Sure, it's theoretically a good idea, but unfortunately I'm not convinced of its practicality.
Kevin Kofler
Adam Jackson wrote:
The difference between a known and an unknown security bug is that, if _you_ know about it, it's virtually certain that someone malicious already does too.
We can't avoid unknown risk exposure. You're arguing for ignoring known risk exposure entirely. Seems a touch irresponsible.
"Unknown" risk exposure can become known after the release and we'd have to respin all our images for every single security fix to address that. This is just not practical.
Also: twelve month.
13 months if you go by that metric, but the 6 months I mentioned are the time between 2 releases, i.e. the time that can pass in the worst case until we release fixed images.
Kevin Kofler
On Wed, 2011-05-18 at 08:57 -0700, Adam Williamson wrote:
Hey, all. The topic of whether and which security issues should block releases has come up several times before. While we haven't actually had many really serious security issues to worry about since the introduction of the current release criteria system, I think it's certainly something we should take into account. At the same time, it's fairly established in practice that we don't just consider anything worth issuing a CVE for as a release-blocking bug. So, to capture what I believe would be the intent of the project, I propose this as an Alpha release criterion for F16 onwards. (For those on devel and security lists who may not be completely familiar with the release criteria / blocker system, this would mean that any bug for an issue which breached the criterion should be considered a release blocker for any Alpha, Beta or Final release).
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
I mostly agree with this criterion with one exception below.
Points to consider:
- Possible variants to the type of vulnerability covered...do we also
want to make local privesc vulns blocking? Conversely, do we want to make only remote *root* execution vulns blocking? I don't know if anyone would want to go as far as making DoS vulns release blocking, but speak up if you would! (Of course there is again the local/remote distinction to consider there: 'all DoS vulns' would be a much tighter standard than 'remote DoS vulns').
- The caveat about where the issue is exploitable is important because
if you can't exploit it from the installer or a live image, it becomes less relevant whether we ship with it or not, because you would be safe with the first post-install update assuming we submitted an update for the issue promptly. But it may be the case that we want to broaden it out to also cover issues that can be exploited from a default DVD install, if we consider the window between install and first update (if updates repos aren't used during installation) to be unacceptable.
I would vote for this slight broadening - that is to make also remotely exploitable issue in the default DVD install a release blocker.
Adam Williamson wrote:
# There must be no known remote code execution vulnerability which could be exploited during installation or during use of a live image shipped with the release
If the installer would download packages during the installation, and an attacker could trick it into downloading and installing malicious code that would run as root once the installed system booted, would that match this criterion?
Because then I'd say yes, let's make this an alpha release criterion – and finally do something about bug 998 before F16 alpha.
Björn Persson
-
Adam Jackson -
Adam Miller -
Adam Williamson -
Björn Persson -
Bruno Wolff III -
Casey Dahlin -
dr johnson -
Jóhann B. Guðmundsson -
Kevin Kofler -
Rahul Sundaram -
Simo Sorce -
Tomas Mraz