Re: what's your Debian uptime?
On 4/19/2013 9:09 AM, Jonathan Dowland wrote:
> On Thu, Apr 18, 2013 at 10:31:35PM -0500, Stan Hoeppner wrote:
>> Second, your methodology doesn't scale. For large scale operations
>> installing new kernel patches every few weeks simply isn't financially
>> feasible/responsible. Even a junior admin's salary is better spent on
>> things other than managing mass kernel upgrades. If one builds
>> minimalist kernels one dramatically decreases frequency of mandatory
>> kernel security patches. The security related flaws are typically in
>> subsystems that are not part of a minimalist kernel.
>
> This is not necessarily true for everyone.
Few things are, computing or otherwise.
> There are a lot of local factors to
> take into account. In a large, heterogenous environment, there's a significant
> investment of time required to properly manage rolling your own kernels across
> different distributions and versions thereof, plus the required time and
> expertise to assess each and every security release regarding a kernel to make
> a proper assessment as to whether you are vulnerable or not, on a system by
> system basis.
Absolutely true for heterogeneous environments. But I specifically
stated large scale. Large scale environments are pretty much always
homogenous--web farms, mail relay and mailbox farms, compute clusters,
etc. This is the ~1000 nodes up class of environment. Here you spend
significant time going over patches, but you save more time doing less
frequent roll outs.
> Managing the roll-out of distribution kernel updates, even if
> you might not be relying on the specific feature that is vulnerable, can be a
> more pragmatic choice. It certainly is at my place of work.
And many places. Far more organizations rely on distribution kernels
than custom, as most organizations are small and rely on vendors, having
minimal or no IT staff of their own.
> There have been interesting examples of vulnerabilities in kernel modules that
> people aren't using but can still be exploited, if the system can be coerced
> into loading the module. Esoteric network protocols are one interesting example.
> An insufficiently-careful look at a security update may mean such a vulnerability
> is left lurking, because it's in a feature one doesn't need. Even if you don't
> build those modules as part of your minimalist kernel, there are some situations
> where a third party can build a module for your running kernel and the machine
> be coerced into loading it (I think there was that bug regarding where cores go
> during segfaults which was one such vector).
>
> On that note, one of the best tips I've ever received regarding keeping systems
> secure is to disable module loading at run time, once the system has all the
> necessary modules loaded to provide the service it is supposed do. As a side
> effect this would prevent you from updating kernel modules whilst keeping the
> host up.
>
> Of course, you may mean disabling module support when you say minimalist kernel.
Since when are they mutually exclusive? I start with
# CONFIG_MODULES is not set
# CONFIG_BLK_DEV_INITRD is not set
Then I only build in drivers needed by my machines, and they're pretty
homogenous. I only have a couple of kernels for the fleet. I also omit
drivers for hardware that may exist but will never be used such as USB,
parallel, etc. I only build in the filesystems I use, EXT2 (for tiny
boot partition) and XFS, and only the deadline elevator. I only include
the processor/memory features I need, same for the block layer, etc. I
simply strip everything I'm able to confirm is unnecessary for my
workloads. This is why my kernels are less than 2MB (using gzip), and
tend to need far less patching than distro kernels.
--
Stan
Reply to: