Something I've complained about when people deploy Linux kernel based OS's is so few people ever tune or customizes their kernels or their base distro's.
-
Something I've complained about when people deploy Linux kernel based OS's is so few people ever tune or customizes their kernels or their base distro's.
This used to be something old school sysadmins would do, as part of the basic security hygiene practice - "If you don't need it, don't include it", which applies to daemons , services and packages.
Kernel compilation is something that rarely seems to happen too..
Do you have hardware encryption capabilities you want things like wolfssl to use? Then sure use #AF_ALG . Anything else? Highly unlikely.
Are you running OpenSwan, or some other VPN or tunneling software that uses encapsulating tunnel options? No? Probably don't need ESP4/ESP6 modules.
Easy for me to call out sure, and i'm taking myself to task as well, since really at work, they don't want people deep diving and compiling kernels in many places. "Trust the vendor" where many mgmt types don't get it or care. "Apt/DNF update and carry on".
Funny because this the antithesis of their "resist patches, and updates" attitude towards software.
The number of mongodb 3.x db's out there because the dev hasn't updated the driver, or the number of npm warnings "this is vulnerable, don't use this" that are ignored are high.
-
Something I've complained about when people deploy Linux kernel based OS's is so few people ever tune or customizes their kernels or their base distro's.
This used to be something old school sysadmins would do, as part of the basic security hygiene practice - "If you don't need it, don't include it", which applies to daemons , services and packages.
Kernel compilation is something that rarely seems to happen too..
Do you have hardware encryption capabilities you want things like wolfssl to use? Then sure use #AF_ALG . Anything else? Highly unlikely.
Are you running OpenSwan, or some other VPN or tunneling software that uses encapsulating tunnel options? No? Probably don't need ESP4/ESP6 modules.
Easy for me to call out sure, and i'm taking myself to task as well, since really at work, they don't want people deep diving and compiling kernels in many places. "Trust the vendor" where many mgmt types don't get it or care. "Apt/DNF update and carry on".
Funny because this the antithesis of their "resist patches, and updates" attitude towards software.
The number of mongodb 3.x db's out there because the dev hasn't updated the driver, or the number of npm warnings "this is vulnerable, don't use this" that are ignored are high.
@Toxic_Flange Back in the day, when there wasn't a kernel update every other day, I would compile my own kernels as well. But that also was back when that was like a multiple-hour-thing. I'm not sure how long it would take today, could be a fun thing to try. But still, I'm not sure I would like to invest the time...
By the way, I don't think it's (only) management. As far as I remember, I havent met any developer (that's 0 - zero) that would care about this.
"Warnings are only warnings, I will fix this when it becomes an error."
Also "why should I update, it works?!?".
Nobody sees (or wants to see?) the benefits. -
@Toxic_Flange Back in the day, when there wasn't a kernel update every other day, I would compile my own kernels as well. But that also was back when that was like a multiple-hour-thing. I'm not sure how long it would take today, could be a fun thing to try. But still, I'm not sure I would like to invest the time...
By the way, I don't think it's (only) management. As far as I remember, I havent met any developer (that's 0 - zero) that would care about this.
"Warnings are only warnings, I will fix this when it becomes an error."
Also "why should I update, it works?!?".
Nobody sees (or wants to see?) the benefits.On relatively modern hardware, with (in theory) a bare minimum kernel (not compiling all options or modules), I imagine it would be faster. However I'm betting each distro makes it hard as hell to deploy within their "native" way of doing things.
Let me counter a bit with, if you have a bare minimum kernel, do you think you would have to update it as much for all the potential risks?
"This version patches X , Y and Z. Oh, I don't need to update because, those aren't modules or something I compiled in!"And agree with all the other points, no notes
-
R relay@relay.infosec.exchange shared this topic
-
Something I've complained about when people deploy Linux kernel based OS's is so few people ever tune or customizes their kernels or their base distro's.
This used to be something old school sysadmins would do, as part of the basic security hygiene practice - "If you don't need it, don't include it", which applies to daemons , services and packages.
Kernel compilation is something that rarely seems to happen too..
Do you have hardware encryption capabilities you want things like wolfssl to use? Then sure use #AF_ALG . Anything else? Highly unlikely.
Are you running OpenSwan, or some other VPN or tunneling software that uses encapsulating tunnel options? No? Probably don't need ESP4/ESP6 modules.
Easy for me to call out sure, and i'm taking myself to task as well, since really at work, they don't want people deep diving and compiling kernels in many places. "Trust the vendor" where many mgmt types don't get it or care. "Apt/DNF update and carry on".
Funny because this the antithesis of their "resist patches, and updates" attitude towards software.
The number of mongodb 3.x db's out there because the dev hasn't updated the driver, or the number of npm warnings "this is vulnerable, don't use this" that are ignored are high.
A lot of that went away when Linux gained decent kernel module support. The kernel you boot with is fairly minimal, but you still have all of the optional bits on disk to load if you need them. If you install something that wants one of the specialised features, you don’t need to figure out why it isn’t working, the module just gets loaded for you. The problem with some of the local vulnerabilities is that the attacks can trigger the auto-loading path.
-
Something I've complained about when people deploy Linux kernel based OS's is so few people ever tune or customizes their kernels or their base distro's.
This used to be something old school sysadmins would do, as part of the basic security hygiene practice - "If you don't need it, don't include it", which applies to daemons , services and packages.
Kernel compilation is something that rarely seems to happen too..
Do you have hardware encryption capabilities you want things like wolfssl to use? Then sure use #AF_ALG . Anything else? Highly unlikely.
Are you running OpenSwan, or some other VPN or tunneling software that uses encapsulating tunnel options? No? Probably don't need ESP4/ESP6 modules.
Easy for me to call out sure, and i'm taking myself to task as well, since really at work, they don't want people deep diving and compiling kernels in many places. "Trust the vendor" where many mgmt types don't get it or care. "Apt/DNF update and carry on".
Funny because this the antithesis of their "resist patches, and updates" attitude towards software.
The number of mongodb 3.x db's out there because the dev hasn't updated the driver, or the number of npm warnings "this is vulnerable, don't use this" that are ignored are high.
@Toxic_Flange This is because you assume that everyone is fully versed in linux administration
Most people do not care if there are some unused services waiting to be used or redundacy or whatever. They just want to have a stable OS working fine on their computers 
But what would be interesting though, is how you could pull these users to easily be able to understand some linux concepts and how to help them change things! Would you have a tutorial to recommend to do that ? -
Something I've complained about when people deploy Linux kernel based OS's is so few people ever tune or customizes their kernels or their base distro's.
This used to be something old school sysadmins would do, as part of the basic security hygiene practice - "If you don't need it, don't include it", which applies to daemons , services and packages.
Kernel compilation is something that rarely seems to happen too..
Do you have hardware encryption capabilities you want things like wolfssl to use? Then sure use #AF_ALG . Anything else? Highly unlikely.
Are you running OpenSwan, or some other VPN or tunneling software that uses encapsulating tunnel options? No? Probably don't need ESP4/ESP6 modules.
Easy for me to call out sure, and i'm taking myself to task as well, since really at work, they don't want people deep diving and compiling kernels in many places. "Trust the vendor" where many mgmt types don't get it or care. "Apt/DNF update and carry on".
Funny because this the antithesis of their "resist patches, and updates" attitude towards software.
The number of mongodb 3.x db's out there because the dev hasn't updated the driver, or the number of npm warnings "this is vulnerable, don't use this" that are ignored are high.
@Toxic_Flange Back in the day I would have to routinely compile to add non interruptible, and low latency patches, so I could edit multi-channel audio without it constantly dropping out. Now, happily, that’s already an option with most distros.
-
R relay@relay.mycrowd.ca shared this topic
-
On relatively modern hardware, with (in theory) a bare minimum kernel (not compiling all options or modules), I imagine it would be faster. However I'm betting each distro makes it hard as hell to deploy within their "native" way of doing things.
Let me counter a bit with, if you have a bare minimum kernel, do you think you would have to update it as much for all the potential risks?
"This version patches X , Y and Z. Oh, I don't need to update because, those aren't modules or something I compiled in!"And agree with all the other points, no notes
@Toxic_Flange Just for shits and giggles, I compiled kernel 7.0.5 with the default Arch config. Took 2:30h.
I probably would do this for a larger, homogenous infrastructure in CI with an automated deployment, but surely not for my private Linux at home. Not just because of the time and configuration overhead, but also to not introduce another variable of uncertainity in case something goes south. -
A lot of that went away when Linux gained decent kernel module support. The kernel you boot with is fairly minimal, but you still have all of the optional bits on disk to load if you need them. If you install something that wants one of the specialised features, you don’t need to figure out why it isn’t working, the module just gets loaded for you. The problem with some of the local vulnerabilities is that the attacks can trigger the auto-loading path.
@david_chisnall Ok, yeah this is a good "technically" point
In my head because the kernel packages you install with the distro includes the modules on disk, I did conflate "in the kernel" and "in the kernel PACKAGE". But isn't that the same thing? How many of those autoloaded modules did you really need? I'm not setting up tunnels or have hardware encryption options, so why are those auto "opt-in" vs defaulted "opt-out". The remediation for many of these at the start was replace those modules with /bin/false and things for many people were just fine without them, so did they really need them? should they have been included on disk?
Makes a difference of what you run on your workstation vs a herd of servers as well. I'll take a different path of thought there.
