On Wednesday 14 May 2003 16:32, Richard B. Johnson wrote:
> 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.
I fix those errors with by booting the Slackware CD with the live
filesystem...
No dependancies on any of the regular disks - then I can fix anything within
reason (haven't tried md raids though).
-
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/
This archive was generated by hypermail 2b29 : Thu May 15 2003 - 22:00:56 EST