OSDev.org

Solar, you seems to have as strong opinions (or should I say belief?) as some of the kernel developers and honestly I don't want to judge who has the "better" ones.

Anyway, all of your examples definitely shouldn't have happened within one version of your distro and managing the upgrade case to a newer version of your distribution is not the job of kernel.org (but the same developers for their respective distribution).

Hi,

Solar wrote:Read /usr/src/linux/Documentation/stable_api_nonsense.txt for the official POV of the kernel dev's. In one line, no driver that's not in the kernel repo (i.e., fully disclosed GPL source) will ever be considered, and they think this is a good thing to do.

AFAIK for Linux "many eyes" is the only thing protecting people from malicious (and/or buggy) code running at CPL=0 with full access to everything.

Pretend for a minute that you're evil, and you want to write a keylogger to steal passwords. My first step would be to think of something people want (e.g. a graphical utility to configure, start, pause and stop virtual machines that supports lots of different VMMs and emulators) and find a believable excuse for this utility to require some sort of kernel module (e.g. to install generic "cross-VMM" TUN/TAP, or to control KVM); and then use the kernel module as a trojan to get the keylogger running.

IMHO there's only 5 approaches to handling this problem:

• The Linux approach: require that all kernel modules are open source (and then complain that hardware manufacturers don't provide open source drivers)
• The Microsoft approach: have some sort of certification program (and hope that the people doing the certification actually catch any problems)
• The "sealed system" approach: make it impossible for anyone to install a kernel module (e.g. build everything into the kernel, with no support for dynamically loaded device drivers, etc)
• The micro-kernel approach: use actual protection (e.g. run device drivers at CPL=3)
• The "bending over with pants down and fingers crossed" approach: Do nothing and hope nobody feels like taking advantage

Cheers,

Brendan

Approach 6:

• Use one of the available (!) techniques for executing untrusted bytecode in a trusted kernel sandbox.

However, I don't see how any of this - even the "all drivers in the kernel" part - makes it necessary to switch ABI, internal architecture etc. on a whim...

Hi,

Solar wrote:However, I don't see how any of this - even the "all drivers in the kernel" part - makes it necessary to switch ABI, internal architecture etc. on a whim...

It doesn't make it necessary to switch ABI, internal architecture etc. on a whim, but if all drives are in the kernel's source code there's no reason not to switch ABI, internal architecture etc. on a whim.


Cheers,

Brendan

Brendan wrote:...but if all drives are in the kernel's source code there's no reason not to switch ABI...

...but they aren't, and they won't.

Oh, I forgot to mention another case that drove me up the walls: ReiserFS 4...

Brendan wrote:Hi,

Pretend for a minute that you're evil, and you want to write a keylogger to steal passwords. My first step would be to think of something people want (e.g. a graphical utility to configure, start, pause and stop virtual machines that supports lots of different VMMs and emulators) and find a believable excuse for this utility to require some sort of kernel module (e.g. to install generic "cross-VMM" TUN/TAP, or to control KVM); and then use the kernel module as a trojan to get the keylogger running.

IMHO there's only 5 approaches to handling this problem:

• The Linux approach: require that all kernel modules are open source (and then complain that hardware manufacturers don't provide open source drivers)

How would the Linux approach help? If you can write a kernel level keylogger you should be able to write a script to compile it automatically on the target's computer with the target's header files and compiler, and that will bypass any "protection".

...but if all drives are in the kernel's source code there's no reason not to switch ABI...

Oh sure there is. Linux drivers break all the time. Imagine if you could just copy over an old version (like using a Windows XP driver on Vista).

Craze Frog wrote:

Brendan wrote:Hi,

Pretend for a minute that you're evil, and you want to write a keylogger to steal passwords. My first step would be to think of something people want (e.g. a graphical utility to configure, start, pause and stop virtual machines that supports lots of different VMMs and emulators) and find a believable excuse for this utility to require some sort of kernel module (e.g. to install generic "cross-VMM" TUN/TAP, or to control KVM); and then use the kernel module as a trojan to get the keylogger running.

IMHO there's only 5 approaches to handling this problem:

• The Linux approach: require that all kernel modules are open source (and then complain that hardware manufacturers don't provide open source drivers)

How would the Linux approach help? If you can write a kernel level keylogger you should be able to write a script to compile it automatically on the target's computer with the target's header files and compiler, and that will bypass any "protection".

You can't assume every linux box (or in this case any kind of box) will have a compiler on it. Having compilers on production machines is a huge security hole for exactly this reason. I rather dislike that so many linux distros default to installing any development tools. But you're right; if a compiler is available anyone could use it to bypass any protection by compiling a kernel module and loading it. Hopefully in that case, the machine is otherwise locked down pretty well, so remote root access is much harder to come by.

quok wrote:Having compilers on production machines is a huge security hole for exactly this reason.

Why is it? if you have access to any account on a machine then you can just as easily wget a copy from somewhere instead of compiling it yourself. Even then, you need root access to modify the kernel in any way (including loading kernel modules or putting them somewhere for the kernel to find).

Basically, a not installing a compiler is only good enough to save a cracker a few minutes. It doesn't add to security, it doesn't break down on security. And in most instances, it doesn't matter at all.

That said, I once had a distro (SuSe) that did not install a compiler, and did not allow it to be installed either. The result was that the machine was crippled for my server purposes. (More rants on that distro available on request)

Combuster wrote:

quok wrote:Having compilers on production machines is a huge security hole for exactly this reason.

Why is it? if you have access to any account on a machine then you can just as easily wget a copy from somewhere instead of compiling it yourself. Even then, you need root access to modify the kernel in any way (including loading kernel modules or putting them somewhere for the kernel to find).

Basically, a not installing a compiler is only good enough to save a cracker a few minutes. It doesn't add to security, it doesn't break down on security. And in most instances, it doesn't matter at all.

That said, I once had a distro (SuSe) that did not install a compiler, and did not allow it to be installed either. The result was that the machine was crippled for my server purposes. (More rants on that distro available on request)

You're right, an intruder could always just wget a copy. However, security is one of those things that's best done in layers, and a few extra minutes spent by an intruder having to download a compiler could be just the couple of minutes you need to save your machine.

Besides, any account with access to a compiler has the potential to gain root access. There's plenty of examples of privilege escalation out there.

Any company I've ever worked at has disallowed compilers on production servers (even internal facing servers) as a matter of security policy. It doesn't fix much of anything, really, but it is does slow people down. It's been my experience that most script kiddies rely on a compiler being available, and as soon as they see that gcc isn't there, they lose interest and go elsewhere.

As for SuSE, I use to love that distro and I do still use it as my primary distro. I've never had that problem, but I've got my own book of rants about the distro. (YaST overwriting config files isn't one of them, though.)