Messages in this thread | | | Date | Wed, 14 May 2003 17:32:56 -0400 (EDT) | From | "Richard B. Johnson" <> | Subject | Re: The disappearing sys_call_table export. |
| |
On Wed, 14 May 2003, Mike Touloumtzis wrote:
> On Wed, May 14, 2003 at 06:34:30AM -0400, Ahmed Masud wrote: > > > > Level of security is a matter of trust. Should the kernel trust a > > distribution provider? No, that is not a reasonable request, because we do > > not control their environment and evaluation proceedures and there are no > > guarentees between the channel that provides the operating system to the > > time it gets installed on a system. > > I don't understand why people are willing to base security arguments > on some sort of bizarre adversarial relationship between the kernel and > the system tools. > > No Unix (even a "secure" one) is designed to run all security-critical > code in the kernel. That would be a bad design anyway, since it would > run lots of code at an unwarranted privilege level. "login" is not > part of the kernel. "su" is not part of the kernel". The boot loader > is not part of the kernel. And so on. > > There is no issue of "trust" between the kernel and the distribution > provider. The distribution provider provides a system, which (like all > Unix-derived systems) is modular and thus has multiple independent > components with security functions. The sum of those parts is what you > should evaluate for security. Yes, the system should include proper > isolation mechanisms to prevent improper privilege escalations. But it > doesn't make sense to even think about what the kernel should do when > the untrusted distribution provides a malicious "/sbin/init".
Not even malicious. For years, it was accepted that if you had physical possesion of a computing system, you could do anything with it that it was capable of.
Not so, with the latest Red Hat distribution (9). You can no longer set init=/bin/bash at the boot prompt.... well you can set it, but then you get an error about killing init. This caused a neighbor a lot of trouble when she accidentally put a blank line in the top of /etc/passwd. Nobody could log-in. I promised to show her how to "break in", but I wasn't able to. I had to take her hard-disk to my house, mount it, and fix the password file. All these "attempts" at so-called security do is make customers pissed.
Cheers, Dick Johnson Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |