[Admin-discuss] blacklisting modules
Hi, This came up today : https://bugzilla.redhat.com/show_bug.cgi?id=647416. It's the second vulnerability in the RDS (some crazy Oracle network protocol) code. As such, the admins have blacklisted the RDS module (since there's no patch for ubuntu yet, and Linus' comment was that the code is likely full of further holes). I'd like to suggest that in future when we find a bug in any of the kernel modules we have no reason to ever use (and there are almost certainly lots of these), we blacklist the module from then on. Someone should add a page to docs with a list of the modules we have blacklisted, and what they do then, so as to make it easier to keep the list across new installs, and so that people can figure out what's wrong when we do decide we need one of them. Thanks Cian
On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote:
I'd like to suggest that in future when we find a bug in any of the kernel modules we have no reason to ever use (and there are almost certainly lots of these), we blacklist the module from then on. Someone should add a page to docs with a list of the modules we have blacklisted, and what they do then, so as to make it easier to keep the list across new installs, and so that people can figure out what's wrong when we do decide we need one of them.
This is a good idea. There's no reason we couldn't include a modprobe conf in a package, that would ensure the blacklist stayed consistent across all machines and new installs. Is there a reason we need to be able to load modules after boot though? -- Andrew Harford Did you hear that Meg? Guys can marry other guys now. So...this is awkward, but I mean, if they can do that, that is pretty much it for you, isn't it? I mean you as well pack it in. Game over. --Stewie Griffin
On 29 October 2010 13:41, Andrew Harford <andrew.harford@redbrick.dcu.ie>wrote:
On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote:
I'd like to suggest that in future when we find a bug in any of the kernel modules we have no reason to ever use (and there are almost certainly lots of these), we blacklist the module from then on. Someone should add a page to docs with a list of the modules we have blacklisted, and what they do then, so as to make it easier to keep the list across new installs, and so that people can figure out what's wrong when we do decide we need one of them.
This is a good idea.
This is a good idea, not sure why we haven't thought of this before :)
There's no reason we couldn't include a modprobe conf in a package, that would ensure the blacklist stayed consistent across all machines and new installs.
Is there a reason we need to be able to load modules after boot though?
-- Andrew Harford
Did you hear that Meg? Guys can marry other guys now. So...this is awkward, but I mean, if they can do that, that is pretty much it for you, isn't it? I mean you as well pack it in. Game over. --Stewie Griffin
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
-- sigless :( - 2010
On Fri, Oct 29, 2010 at 01:41:47PM +0100, Andrew Harford wrote:
On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote:
I'd like to suggest that in future when we find a bug in any of the kernel modules we have no reason to ever use (and there are almost certainly lots of these), we blacklist the module from then on. Someone should add a page to docs with a list of the modules we have blacklisted, and what they do then, so as to make it easier to keep the list across new installs, and so that people can figure out what's wrong when we do decide we need one of them.
This is a good idea. +1 There's no reason we couldn't include a modprobe conf in a package, that would ensure the blacklist stayed consistent across all machines and new installs. yes, I am definitely in favour of this.
Is there a reason we need to be able to load modules after boot though?
http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-3-car... Just from briefly reading this, it seems that they're pretty handy. I'm not sold on disabling the ability to.
-- Andrew Harford
Did you hear that Meg? Guys can marry other guys now. So...this is awkward, but I mean, if they can do that, that is pretty much it for you, isn't it? I mean you as well pack it in. Game over. --Stewie Griffin
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
On Fri, Oct 29, 2010 at 04:06:37PM +0100, Austin Halpin wrote:
On Fri, Oct 29, 2010 at 01:41:47PM +0100, Andrew Harford wrote:
On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote:
I'd like to suggest that in future when we find a bug in any of the kernel modules we have no reason to ever use (and there are almost certainly lots of these), we blacklist the module from then on. Someone should add a page to docs with a list of the modules we have blacklisted, and what they do then, so as to make it easier to keep the list across new installs, and so that people can figure out what's wrong when we do decide we need one of them.
This is a good idea. +1 There's no reason we couldn't include a modprobe conf in a package, that would ensure the blacklist stayed consistent across all machines and new installs. yes, I am definitely in favour of this.
Is there a reason we need to be able to load modules after boot though?
http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-3-car...
Just from briefly reading this, it seems that they're pretty handy. I'm not sold on disabling the ability to.
Theoretically, they're pretty useful. I'm not sure that there are that many use cases for us in particular. Certainly, I can't think of any.
-- Andrew Harford
Did you hear that Meg? Guys can marry other guys now. So...this is awkward, but I mean, if they can do that, that is pretty much it for you, isn't it? I mean you as well pack it in. Game over. --Stewie Griffin
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
After barely reading this thread I'd be all for blaklisting shit code we've no use for. And loading modules after boot is really handy, I can't think of a use RedBrick would have for doing it though, but I use modprobe all the time. On Fri, Oct 29, 2010 at 04:17:13PM +0100, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 04:06:37PM +0100, Austin Halpin wrote:
On Fri, Oct 29, 2010 at 01:41:47PM +0100, Andrew Harford wrote:
On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote:
I'd like to suggest that in future when we find a bug in any of the kernel modules we have no reason to ever use (and there are almost certainly lots of these), we blacklist the module from then on. Someone should add a page to docs with a list of the modules we have blacklisted, and what they do then, so as to make it easier to keep the list across new installs, and so that people can figure out what's wrong when we do decide we need one of them.
This is a good idea. +1 There's no reason we couldn't include a modprobe conf in a package, that would ensure the blacklist stayed consistent across all machines and new installs. yes, I am definitely in favour of this.
Is there a reason we need to be able to load modules after boot though?
http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-3-car...
Just from briefly reading this, it seems that they're pretty handy. I'm not sold on disabling the ability to.
Theoretically, they're pretty useful. I'm not sure that there are that many use cases for us in particular. Certainly, I can't think of any.
-- Andrew Harford
Did you hear that Meg? Guys can marry other guys now. So...this is awkward, but I mean, if they can do that, that is pretty much it for you, isn't it? I mean you as well pack it in. Game over. --Stewie Griffin
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
On Fri, Oct 29, 2010 at 11:45:51PM +0100, James Reggie Reilly wrote:
After barely reading this thread I'd be all for blaklisting shit code we've no use for.
And loading modules after boot is really handy, I can't think of a use RedBrick would have for doing it though, but I use modprobe all the time.
So, continuing on this discussion Firstly, we should blacklist X.25 (net-pf-9 is the module). I don't think it realistically affects us, but CVE-2010-3873 gives you a remote DOS based on some bug in this code. Secondly, can I suggest testing disabling module loading on carbon? If it works there, we can look at moving it to some of the more important machines, if it doesn't, we can just reboot it, without any great effects, given that it runs no real services. Thanks Cian
On Fri, Oct 29, 2010 at 04:17:13PM +0100, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 04:06:37PM +0100, Austin Halpin wrote:
On Fri, Oct 29, 2010 at 01:41:47PM +0100, Andrew Harford wrote:
On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote:
I'd like to suggest that in future when we find a bug in any of the kernel modules we have no reason to ever use (and there are almost certainly lots of these), we blacklist the module from then on. Someone should add a page to docs with a list of the modules we have blacklisted, and what they do then, so as to make it easier to keep the list across new installs, and so that people can figure out what's wrong when we do decide we need one of them.
This is a good idea. +1 There's no reason we couldn't include a modprobe conf in a package, that would ensure the blacklist stayed consistent across all machines and new installs. yes, I am definitely in favour of this.
Is there a reason we need to be able to load modules after boot though?
http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-3-car...
Just from briefly reading this, it seems that they're pretty handy. I'm not sold on disabling the ability to.
Theoretically, they're pretty useful. I'm not sure that there are that many use cases for us in particular. Certainly, I can't think of any.
-- Andrew Harford
Did you hear that Meg? Guys can marry other guys now. So...this is awkward, but I mean, if they can do that, that is pretty much it for you, isn't it? I mean you as well pack it in. Game over. --Stewie Griffin
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
On Mon, Nov 08, 2010 at 12:05:05AM +0000, Cian Brennan wrote:
Secondly, can I suggest testing disabling module loading on carbon? If it works there, we can look at moving it to some of the more important machines, if it doesn't, we can just reboot it, without any great effects, given that it runs no real services.
+1 We should do it Friday, since carbon will be going down then anyway. -- Andrew Harford I spent my whole life trying not to be careless. Women and children can be careless. But not men. --Don Vito Corleone
Top post FTW. On Mon, Nov 08, 2010 at 12:05:05AM +0000, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 11:45:51PM +0100, James Reggie Reilly wrote:
After barely reading this thread I'd be all for blaklisting shit code we've no use for.
And loading modules after boot is really handy, I can't think of a use RedBrick would have for doing it though, but I use modprobe all the time.
So, continuing on this discussion
Firstly, we should blacklist X.25 (net-pf-9 is the module). I don't think it realistically affects us, but CVE-2010-3873 gives you a remote DOS based on some bug in this code.
Secondly, can I suggest testing disabling module loading on carbon? If it works there, we can look at moving it to some of the more important machines, if it doesn't, we can just reboot it, without any great effects, given that it runs no real services.
Thanks Cian
I'd be up for this alright. We should open a ticket for this in, you know, our ticketing system. We can then add to that ticket the list of modules to blacklist, instead of a mail buried in my inbox.
On Fri, Oct 29, 2010 at 04:17:13PM +0100, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 04:06:37PM +0100, Austin Halpin wrote:
On Fri, Oct 29, 2010 at 01:41:47PM +0100, Andrew Harford wrote:
On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote:
I'd like to suggest that in future when we find a bug in any of the kernel modules we have no reason to ever use (and there are almost certainly lots of these), we blacklist the module from then on. Someone should add a page to docs with a list of the modules we have blacklisted, and what they do then, so as to make it easier to keep the list across new installs, and so that people can figure out what's wrong when we do decide we need one of them.
This is a good idea. +1 There's no reason we couldn't include a modprobe conf in a package, that would ensure the blacklist stayed consistent across all machines and new installs. yes, I am definitely in favour of this.
Is there a reason we need to be able to load modules after boot though?
http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-3-car...
Just from briefly reading this, it seems that they're pretty handy. I'm not sold on disabling the ability to.
Theoretically, they're pretty useful. I'm not sure that there are that many use cases for us in particular. Certainly, I can't think of any.
-- Andrew Harford
Did you hear that Meg? Guys can marry other guys now. So...this is awkward, but I mean, if they can do that, that is pretty much it for you, isn't it? I mean you as well pack it in. Game over. --Stewie Griffin
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
On Mon, Nov 08, 2010 at 12:13:38AM +0000, James Reggie Reilly wrote:
Top post FTW.
On Mon, Nov 08, 2010 at 12:05:05AM +0000, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 11:45:51PM +0100, James Reggie Reilly wrote:
After barely reading this thread I'd be all for blaklisting shit code we've no use for.
And loading modules after boot is really handy, I can't think of a use RedBrick would have for doing it though, but I use modprobe all the time.
So, continuing on this discussion
Firstly, we should blacklist X.25 (net-pf-9 is the module). I don't think it realistically affects us, but CVE-2010-3873 gives you a remote DOS based on some bug in this code.
Secondly, can I suggest testing disabling module loading on carbon? If it works there, we can look at moving it to some of the more important machines, if it doesn't, we can just reboot it, without any great effects, given that it runs no real services.
Thanks Cian
I'd be up for this alright. We should open a ticket for this in, you know, our ticketing system. We can then add to that ticket the list of modules to blacklist, instead of a mail buried in my inbox.
This man is a genius! Also, I agree with doing it on friday when we're taking the system down anyway.
On Fri, Oct 29, 2010 at 04:17:13PM +0100, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 04:06:37PM +0100, Austin Halpin wrote:
On Fri, Oct 29, 2010 at 01:41:47PM +0100, Andrew Harford wrote:
On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote: > I'd like to suggest that in future when we find a bug in any of the kernel > modules we have no reason to ever use (and there are almost certainly lots of > these), we blacklist the module from then on. Someone should add a page to docs > with a list of the modules we have blacklisted, and what they do then, so as to > make it easier to keep the list across new installs, and so that people can > figure out what's wrong when we do decide we need one of them.
This is a good idea. +1 There's no reason we couldn't include a modprobe conf in a package, that would ensure the blacklist stayed consistent across all machines and new installs. yes, I am definitely in favour of this.
Is there a reason we need to be able to load modules after boot though?
http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-3-car...
Just from briefly reading this, it seems that they're pretty handy. I'm not sold on disabling the ability to.
Theoretically, they're pretty useful. I'm not sure that there are that many use cases for us in particular. Certainly, I can't think of any.
-- Andrew Harford
Did you hear that Meg? Guys can marry other guys now. So...this is awkward, but I mean, if they can do that, that is pretty much it for you, isn't it? I mean you as well pack it in. Game over. --Stewie Griffin
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
On Mon, Nov 08, 2010 at 12:15:30AM +0000, Austin Halpin wrote:
On Mon, Nov 08, 2010 at 12:13:38AM +0000, James Reggie Reilly wrote:
Top post FTW.
On Mon, Nov 08, 2010 at 12:05:05AM +0000, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 11:45:51PM +0100, James Reggie Reilly wrote:
After barely reading this thread I'd be all for blaklisting shit code we've no use for.
And loading modules after boot is really handy, I can't think of a use RedBrick would have for doing it though, but I use modprobe all the time.
So, continuing on this discussion
Firstly, we should blacklist X.25 (net-pf-9 is the module). I don't think it realistically affects us, but CVE-2010-3873 gives you a remote DOS based on some bug in this code.
Secondly, can I suggest testing disabling module loading on carbon? If it works there, we can look at moving it to some of the more important machines, if it doesn't, we can just reboot it, without any great effects, given that it runs no real services.
Thanks Cian
I'd be up for this alright. We should open a ticket for this in, you know, our ticketing system. We can then add to that ticket the list of modules to blacklist, instead of a mail buried in my inbox.
This man is a genius! Also, I agree with doing it on friday when we're taking the system down anyway.
Can I suggest doing it before friday, so we have a day or two to let problems crop up? If we only do it Friday, it's entirely possible there will be problems we just don't notice.
On Fri, Oct 29, 2010 at 04:17:13PM +0100, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 04:06:37PM +0100, Austin Halpin wrote:
On Fri, Oct 29, 2010 at 01:41:47PM +0100, Andrew Harford wrote: > On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote: > > I'd like to suggest that in future when we find a bug in any of the kernel > > modules we have no reason to ever use (and there are almost certainly lots of > > these), we blacklist the module from then on. Someone should add a page to docs > > with a list of the modules we have blacklisted, and what they do then, so as to > > make it easier to keep the list across new installs, and so that people can > > figure out what's wrong when we do decide we need one of them. > > This is a good idea. +1 > There's no reason we couldn't include a modprobe conf in a package, that > would ensure the blacklist stayed consistent across all machines and new > installs. yes, I am definitely in favour of this.
> Is there a reason we need to be able to load modules after boot though?
http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-3-car...
Just from briefly reading this, it seems that they're pretty handy. I'm not sold on disabling the ability to.
Theoretically, they're pretty useful. I'm not sure that there are that many use cases for us in particular. Certainly, I can't think of any.
> -- > Andrew Harford > > Did you hear that Meg? Guys can marry other guys now. So...this is > awkward, but I mean, if they can do that, that is pretty much it for you, > isn't it? I mean you as well pack it in. Game over. --Stewie Griffin > > _______________________________________________ > Admin-discuss mailing list > Admin-discuss@lists.redbrick.dcu.ie > http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss >
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
On Mon, Nov 08, 2010 at 12:17:17AM +0000, Cian Brennan wrote:
On Mon, Nov 08, 2010 at 12:15:30AM +0000, Austin Halpin wrote:
On Mon, Nov 08, 2010 at 12:13:38AM +0000, James Reggie Reilly wrote:
Top post FTW.
On Mon, Nov 08, 2010 at 12:05:05AM +0000, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 11:45:51PM +0100, James Reggie Reilly wrote:
After barely reading this thread I'd be all for blaklisting shit code we've no use for.
And loading modules after boot is really handy, I can't think of a use RedBrick would have for doing it though, but I use modprobe all the time.
So, continuing on this discussion
Firstly, we should blacklist X.25 (net-pf-9 is the module). I don't think it realistically affects us, but CVE-2010-3873 gives you a remote DOS based on some bug in this code.
Secondly, can I suggest testing disabling module loading on carbon? If it works there, we can look at moving it to some of the more important machines, if it doesn't, we can just reboot it, without any great effects, given that it runs no real services.
Thanks Cian
I'd be up for this alright. We should open a ticket for this in, you know, our ticketing system. We can then add to that ticket the list of modules to blacklist, instead of a mail buried in my inbox.
This man is a genius! Also, I agree with doing it on friday when we're taking the system down anyway.
Can I suggest doing it before friday, so we have a day or two to let problems crop up? If we only do it Friday, it's entirely possible there will be problems we just don't notice.
This seems like a reasonable idea. I see no reason this could not be done tomorrow/Tuesday and test it during the week. Ideally we'd want longer than a few days to test this under all possible conditions, but a few days should tell us if we're doing somehing retarded.
On Fri, Oct 29, 2010 at 04:17:13PM +0100, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 04:06:37PM +0100, Austin Halpin wrote: > On Fri, Oct 29, 2010 at 01:41:47PM +0100, Andrew Harford wrote: > > On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote: > > > I'd like to suggest that in future when we find a bug in any of the kernel > > > modules we have no reason to ever use (and there are almost certainly lots of > > > these), we blacklist the module from then on. Someone should add a page to docs > > > with a list of the modules we have blacklisted, and what they do then, so as to > > > make it easier to keep the list across new installs, and so that people can > > > figure out what's wrong when we do decide we need one of them. > > > > This is a good idea. > +1 > > There's no reason we couldn't include a modprobe conf in a package, that > > would ensure the blacklist stayed consistent across all machines and new > > installs. > yes, I am definitely in favour of this. > > > Is there a reason we need to be able to load modules after boot though? > > http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-3-car... > > Just from briefly reading this, it seems that they're pretty handy. I'm > not sold on disabling the ability to. > Theoretically, they're pretty useful. I'm not sure that there are that many use cases for us in particular. Certainly, I can't think of any.
> > -- > > Andrew Harford > > > > Did you hear that Meg? Guys can marry other guys now. So...this is > > awkward, but I mean, if they can do that, that is pretty much it for you, > > isn't it? I mean you as well pack it in. Game over. --Stewie Griffin > > > > _______________________________________________ > > Admin-discuss mailing list > > Admin-discuss@lists.redbrick.dcu.ie > > http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss > > >
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
On Mon, Nov 08, 2010 at 12:22:57AM +0000, James Reggie Reilly wrote:
On Mon, Nov 08, 2010 at 12:17:17AM +0000, Cian Brennan wrote:
On Mon, Nov 08, 2010 at 12:15:30AM +0000, Austin Halpin wrote:
On Mon, Nov 08, 2010 at 12:13:38AM +0000, James Reggie Reilly wrote:
Top post FTW.
On Mon, Nov 08, 2010 at 12:05:05AM +0000, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 11:45:51PM +0100, James Reggie Reilly wrote:
After barely reading this thread I'd be all for blaklisting shit code we've no use for.
And loading modules after boot is really handy, I can't think of a use RedBrick would have for doing it though, but I use modprobe all the time.
So, continuing on this discussion
Firstly, we should blacklist X.25 (net-pf-9 is the module). I don't think it realistically affects us, but CVE-2010-3873 gives you a remote DOS based on some bug in this code.
Secondly, can I suggest testing disabling module loading on carbon? If it works there, we can look at moving it to some of the more important machines, if it doesn't, we can just reboot it, without any great effects, given that it runs no real services.
Thanks Cian
I'd be up for this alright. We should open a ticket for this in, you know, our ticketing system. We can then add to that ticket the list of modules to blacklist, instead of a mail buried in my inbox.
This man is a genius! Also, I agree with doing it on friday when we're taking the system down anyway.
Can I suggest doing it before friday, so we have a day or two to let problems crop up? If we only do it Friday, it's entirely possible there will be problems we just don't notice.
This seems like a reasonable idea. I see no reason this could not be done tomorrow/Tuesday and test it during the week. Ideally we'd want longer than a few days to test this under all possible conditions, but a few days should tell us if we're doing somehing retarded.
While we're testing stuff on carbon, should we build unscd from source and test it there? It can't be too far from being accepted into sid, so we may aswell test it on carbon, since it's an experimental box anyway...
On Fri, Oct 29, 2010 at 04:17:13PM +0100, Cian Brennan wrote: > On Fri, Oct 29, 2010 at 04:06:37PM +0100, Austin Halpin wrote: > > On Fri, Oct 29, 2010 at 01:41:47PM +0100, Andrew Harford wrote: > > > On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote: > > > > I'd like to suggest that in future when we find a bug in any of the kernel > > > > modules we have no reason to ever use (and there are almost certainly lots of > > > > these), we blacklist the module from then on. Someone should add a page to docs > > > > with a list of the modules we have blacklisted, and what they do then, so as to > > > > make it easier to keep the list across new installs, and so that people can > > > > figure out what's wrong when we do decide we need one of them. > > > > > > This is a good idea. > > +1 > > > There's no reason we couldn't include a modprobe conf in a package, that > > > would ensure the blacklist stayed consistent across all machines and new > > > installs. > > yes, I am definitely in favour of this. > > > > > Is there a reason we need to be able to load modules after boot though? > > > > http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-3-car... > > > > Just from briefly reading this, it seems that they're pretty handy. I'm > > not sold on disabling the ability to. > > > Theoretically, they're pretty useful. I'm not sure that there are that many use > cases for us in particular. Certainly, I can't think of any. > > > > -- > > > Andrew Harford > > > > > > Did you hear that Meg? Guys can marry other guys now. So...this is > > > awkward, but I mean, if they can do that, that is pretty much it for you, > > > isn't it? I mean you as well pack it in. Game over. --Stewie Griffin > > > > > > _______________________________________________ > > > Admin-discuss mailing list > > > Admin-discuss@lists.redbrick.dcu.ie > > > http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss > > > > > > > _______________________________________________ > Admin-discuss mailing list > Admin-discuss@lists.redbrick.dcu.ie > http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss >
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
On Mon, Nov 08, 2010 at 12:22:57AM +0000, James Reggie Reilly wrote:
On Mon, Nov 08, 2010 at 12:17:17AM +0000, Cian Brennan wrote:
On Mon, Nov 08, 2010 at 12:15:30AM +0000, Austin Halpin wrote:
On Mon, Nov 08, 2010 at 12:13:38AM +0000, James Reggie Reilly wrote:
Top post FTW.
On Mon, Nov 08, 2010 at 12:05:05AM +0000, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 11:45:51PM +0100, James Reggie Reilly wrote:
After barely reading this thread I'd be all for blaklisting shit code we've no use for.
And loading modules after boot is really handy, I can't think of a use RedBrick would have for doing it though, but I use modprobe all the time.
So, continuing on this discussion
Firstly, we should blacklist X.25 (net-pf-9 is the module). I don't think it realistically affects us, but CVE-2010-3873 gives you a remote DOS based on some bug in this code.
Secondly, can I suggest testing disabling module loading on carbon? If it works there, we can look at moving it to some of the more important machines, if it doesn't, we can just reboot it, without any great effects, given that it runs no real services.
Thanks Cian
I'd be up for this alright. We should open a ticket for this in, you know, our ticketing system. We can then add to that ticket the list of modules to blacklist, instead of a mail buried in my inbox.
This man is a genius! Also, I agree with doing it on friday when we're taking the system down anyway.
Can I suggest doing it before friday, so we have a day or two to let problems crop up? If we only do it Friday, it's entirely possible there will be problems we just don't notice.
This seems like a reasonable idea. I see no reason this could not be done tomorrow/Tuesday and test it during the week. Ideally we'd want longer than a few days to test this under all possible conditions, but a few days should tell us if we're doing somehing retarded.
I've disabled module loading on carbon. Be sure to point out if things start to break and then we can take a look at fixing whatever's going wrong.
On Fri, Oct 29, 2010 at 04:17:13PM +0100, Cian Brennan wrote: > On Fri, Oct 29, 2010 at 04:06:37PM +0100, Austin Halpin wrote: > > On Fri, Oct 29, 2010 at 01:41:47PM +0100, Andrew Harford wrote: > > > On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote: > > > > I'd like to suggest that in future when we find a bug in any of the kernel > > > > modules we have no reason to ever use (and there are almost certainly lots of > > > > these), we blacklist the module from then on. Someone should add a page to docs > > > > with a list of the modules we have blacklisted, and what they do then, so as to > > > > make it easier to keep the list across new installs, and so that people can > > > > figure out what's wrong when we do decide we need one of them. > > > > > > This is a good idea. > > +1 > > > There's no reason we couldn't include a modprobe conf in a package, that > > > would ensure the blacklist stayed consistent across all machines and new > > > installs. > > yes, I am definitely in favour of this. > > > > > Is there a reason we need to be able to load modules after boot though? > > > > http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-3-car... > > > > Just from briefly reading this, it seems that they're pretty handy. I'm > > not sold on disabling the ability to. > > > Theoretically, they're pretty useful. I'm not sure that there are that many use > cases for us in particular. Certainly, I can't think of any. > > > > -- > > > Andrew Harford > > > > > > Did you hear that Meg? Guys can marry other guys now. So...this is > > > awkward, but I mean, if they can do that, that is pretty much it for you, > > > isn't it? I mean you as well pack it in. Game over. --Stewie Griffin > > > > > > _______________________________________________ > > > Admin-discuss mailing list > > > Admin-discuss@lists.redbrick.dcu.ie > > > http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss > > > > > > > _______________________________________________ > Admin-discuss mailing list > Admin-discuss@lists.redbrick.dcu.ie > http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss >
On Mon, Nov 08, 2010 at 12:13:38AM +0000, James Reggie Reilly wrote:
Top post FTW.
On Mon, Nov 08, 2010 at 12:05:05AM +0000, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 11:45:51PM +0100, James Reggie Reilly wrote:
After barely reading this thread I'd be all for blaklisting shit code we've no use for.
And loading modules after boot is really handy, I can't think of a use RedBrick would have for doing it though, but I use modprobe all the time.
So, continuing on this discussion
Firstly, we should blacklist X.25 (net-pf-9 is the module). I don't think it realistically affects us, but CVE-2010-3873 gives you a remote DOS based on some bug in this code.
Secondly, can I suggest testing disabling module loading on carbon? If it works there, we can look at moving it to some of the more important machines, if it doesn't, we can just reboot it, without any great effects, given that it runs no real services.
Thanks Cian
I'd be up for this alright. We should open a ticket for this in, you know, our ticketing system. We can then add to that ticket the list of modules to blacklist, instead of a mail buried in my inbox.
Well, ideally we should do both :-) The ticket for what we've decided to do, the mails here for when we're still deciding.
On Fri, Oct 29, 2010 at 04:17:13PM +0100, Cian Brennan wrote:
On Fri, Oct 29, 2010 at 04:06:37PM +0100, Austin Halpin wrote:
On Fri, Oct 29, 2010 at 01:41:47PM +0100, Andrew Harford wrote:
On Fri, Oct 29, 2010 at 11:34:58AM +0100, Cian Brennan wrote: > I'd like to suggest that in future when we find a bug in any of the kernel > modules we have no reason to ever use (and there are almost certainly lots of > these), we blacklist the module from then on. Someone should add a page to docs > with a list of the modules we have blacklisted, and what they do then, so as to > make it easier to keep the list across new installs, and so that people can > figure out what's wrong when we do decide we need one of them.
This is a good idea. +1 There's no reason we couldn't include a modprobe conf in a package, that would ensure the blacklist stayed consistent across all machines and new installs. yes, I am definitely in favour of this.
Is there a reason we need to be able to load modules after boot though?
http://www.crashcourse.ca/introduction-linux-kernel-programming/lesson-3-car...
Just from briefly reading this, it seems that they're pretty handy. I'm not sold on disabling the ability to.
Theoretically, they're pretty useful. I'm not sure that there are that many use cases for us in particular. Certainly, I can't think of any.
-- Andrew Harford
Did you hear that Meg? Guys can marry other guys now. So...this is awkward, but I mean, if they can do that, that is pretty much it for you, isn't it? I mean you as well pack it in. Game over. --Stewie Griffin
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
_______________________________________________ Admin-discuss mailing list Admin-discuss@lists.redbrick.dcu.ie http://lists.redbrick.dcu.ie/mailman/listinfo/admin-discuss
Firstly, we should blacklist X.25 (net-pf-9 is the module). I don't think it realistically affects us, but CVE-2010-3873 gives you a remote DOS based on some bug in this code.
Secondly, can I suggest testing disabling module loading on carbon? If it works there, we can look at moving it to some of the more important machines, if it doesn't, we can just reboot it, without any great effects, given that it runs no real services.
Thanks Cian
I'd be up for this alright. We should open a ticket for this in, you know, our ticketing system. We can then add to that ticket the list of modules to blacklist, instead of a mail buried in my inbox.
Well, ideally we should do both :-) The ticket for what we've decided to do, the mails here for when we're still deciding.
Tickets should be tied into mails anyway. Someone needs to fix that. Yeah, modules idea sounds good. Do it, etc.
On Mon, Nov 08, 2010 at 12:23:22AM +0000, Andrew Martin wrote:
Firstly, we should blacklist X.25 (net-pf-9 is the module). I don't think it realistically affects us, but CVE-2010-3873 gives you a remote DOS based on some bug in this code.
Secondly, can I suggest testing disabling module loading on carbon? If it works there, we can look at moving it to some of the more important machines, if it doesn't, we can just reboot it, without any great effects, given that it runs no real services.
Thanks Cian
I'd be up for this alright. We should open a ticket for this in, you know, our ticketing system. We can then add to that ticket the list of modules to blacklist, instead of a mail buried in my inbox.
Well, ideally we should do both :-) The ticket for what we've decided to do, the mails here for when we're still deciding.
Tickets should be tied into mails anyway. Someone needs to fix that.
Yeah, modules idea sounds good. Do it, etc.
OSHI- I wass working on this. Will finish it by the close of business friday.
participants (6)
-
Andrew Harford -
Andrew Martin -
Austin Halpin -
Cian Brennan -
James "Reggie" Reilly -
kat farrell