(Tune of "Running Free", by Iron Maiden)
Kernel bug, core runs wild,
Space/time twists and gets compiled.
Wormholes open and bring to me,
Linux Kernel Version 3!
I'm running 3, yeah, I'm running 3!
I'm running 3, yeah, I'm running 3!
Got support for Tbyte RAM,
The newest arch is leg of lamb.
Max cpus, one thousand now,
Neg latency gives quite a pow.
Men in Black zap my brains,
Melt the hard-disk, and what remains.
There's nothing left for you to see
That my machine was running 3!
On Tue, 18 Jun 2002, Myrddin Ambrosius wrote:
> Hi all,
>
> With the discussion on kernel crypto a while back,
> there was one very important recurring element that I
> would like someone to clarify for me.
>
> The issue is this. My understanding is that -all-
> hardware access should be through the kernel, partly
> so that similar hardware can have a similar API, but
> also so that kernel security code (eg: capabilities)
> applies to ALL hardware and ALL lower-level
> operations.
>
> However, there were a number of mentions of userland
> hardware drivers, which did NOT operate through the
> kernel. (This was in reference to why it wouldn't be
> necessary to have a kernel-level driver for the
> Motorola M190 crypto chip.)
>
> If you can blithely ignore restrictions placed by the
> kernel on some piece of hardware, and access it
> directly, then surely this would apply to any
> hardware. Including disk drives, RAM, etc.
>
> I could be wrong (and I hope, very much, that I am),
> but if my understanding is correct, then that's a hole
> you could drive a truck through, and have room to
> spare.
>
> This isn't intended as a critisism of anyone, or of
> any decisions made regarding the way the kernel
> operates. (I know my phrasing leaves a lot to be
> desired. Sometimes I think my best chance of a long
> life would be to take a vow of silence and become a
> monk.)
>
> I'd really appreciate it if someone could clarify this
> for me, especially the security aspect of non-kernel
> drivers.
No hole you can drive through. A process with a UID of 0 and
a GID of 0 can do anything it wants. It can execute iopl(3)
and set an I/O permission level that allows it to directly access
hardware I/O ports, etc. It can also turn off interrupts. Basically,
it can do anything, since such a process can also memory-map anything.
Users are not supposed to execute as 'root'. Also, only certain
priviliged tasks execute as root. Ignore that this account
"seems-to-be" [email protected]. This is an anti-spam trick.
The real root on this machine is called "system". Names mean nothing
to Unix, it's the UID/GID that counts.
You can make a priviliged task by setting the UID/GID to zero in
the first few lines of 'C' code of main(). This will fail unless
the resulting executable has its SUID bit set (chmod 4755 filename).
Further, this file has to execute in a root-owned directory. Once
these conditions are satisfied, the program can do anything it wants.
main()
{
setuid(0);
setgid(0);
iopl(3);
mmap(everything);
destroy_the_world();
}
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
On Tue, 18 Jun 2002, Myrddin Ambrosius wrote:
> If you can blithely ignore restrictions placed by the
> kernel on some piece of hardware, and access it
> directly, then surely this would apply to any
> hardware. Including disk drives, RAM, etc.
iopl(2), chmod(1) and friends, hardware frobbing isn't a free for all.
Then again if you're root...
Regards,
Zwane Mwaikambo
--
http://function.linuxpower.ca
Le mar 18/06/2002 ? 17:06, Myrddin Ambrosius a ?crit :
> The issue is this. My understanding is that -all-
> hardware access should be through the kernel, partly
> so that similar hardware can have a similar API, but
> also so that kernel security code (eg: capabilities)
> applies to ALL hardware and ALL lower-level
> operations.
You want to forbid XFree86's DRI ?
Xav
--- Xavier Bestel <[email protected]> wrote:
> Le mar 18/06/2002 ? 17:06, Myrddin Ambrosius a ?crit
> :
> > The issue is this. My understanding is that -all-
> > hardware access should be through the kernel,
> partly
> > so that similar hardware can have a similar API,
> but
> > also so that kernel security code (eg:
> capabilities)
> > applies to ALL hardware and ALL lower-level
> > operations.
>
> You want to forbid XFree86's DRI ?
No, the kernel's DRM provides a nice kernel layer for
XFree's DRI, which covers all the security issues.
Well, provided the DRM code gets enough drivers.
Personally, I'd like to see more fine-control of
graphics hardware end up in the kernel, partly to
avoid some of the nastier security risks (such as
having to run X servers as root! bleagh!) but also
because the kernel has to have a whole lot of control
anyway.
The sheer number of possible displays you can put into
any given one of the fantastically large number of
virtual consoles makes for an interesting challange.
(On older kernels, changing to and from virtual
terminal when running an svgalib app could do some
VERY interesting things to your display.)
When you start looking at running X under multiple
resolutions on the same machine, or even running
multiple X servers (which I -think- is now possible),
things don't get any better.
If the kernel's various graphics components (DRM,
framebuffers, etc) handled the low-level stuff, you
don't get multiple pieces of software each trying to
drive the screen at a different rate. You could even
have two pieces of software access the same virtual
terminal at different resolutions, because the kernel
would eliminate the "conflict".
I understand that, prior to framebuffers going in,
there were a number of (cough!) lengthy discussions on
the safety and stability of high-level code in the
kernel. I honestly believe that this is the flip-side
of that same debate. Whether it is safe and stable to
have low-level code in userland.
I honestly believe that too much low-level code or
access in userland is just as destabilizing (and
potentially far more dangerous) than high-level code
in the kernel.
Someone else mentioned all the wonderful stuff root
can do. Root's a cool toy, but in the end, root is
still a product of the kernel's imagination. There is
no physical chunk of machinary in a computer that can
be called "root". Unless your spider-plant has grown.
Therefore, to argue that root can do anything is not
entirely true. (In fact, Linux' Capabilities
demonstrates this, nicely. It is possible to set the
capabilities such that nothing root can do can
re-enable any capabilities removed.)
It would be too soon to "retire" root, because I don't
think anyone's entirely happy with the alternatives
that exist. (If they were, Linux would have lost root
before version 1.0! I can remember patches almost the
size of the kernel!) Maybe, someday, someone'll figure
out a rootless system that is generally acceptable.
On the other hand, if the small handful of actual
instructions (not apps, not even functions, just the
instructions) that -need- super-user privs were all
encapsulated inside kernel system calls, then you
don't risk running a root-kit-o-matic every time you
boot X, or some other server that currently needs root
privs.
One reason for NOT doing this is that it takes time to
switch between contexts. Deliberately adding a whole
bunch of switches would seem to be remarkably stupid.
Doubly so, when you're adding switches to maybe run
half a dozen lines. For stuff that's used heavily,
there's probably less time penalty in typing the code
in by hand into the server, and running as root, than
all the constant switching.
I don't have to like it, but I can't find any solid
argument against this. Good solutions are efficient,
and efficient != slower than a snail on salt.
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
--- "Richard B. Johnson" <[email protected]>
wrote:
> No hole you can drive through. A process with a UID
> of 0 and
> a GID of 0 can do anything it wants. It can execute
> iopl(3)
> and set an I/O permission level that allows it to
> directly access
> hardware I/O ports, etc. It can also turn off
> interrupts. Basically,
> it can do anything, since such a process can also
> memory-map anything.
But since it is the kernel that permits that (by
definition, since somebody has to check the UID & GID!
:) then the kernel can also restrict that.
The system admin account (UID/GID 0) could just as
easily access a virtual memory map, virtual I/O ports,
etc, with the kernel then handling how that maps onto
the physical world, and even IF it does.
> Users are not supposed to execute as 'root'. Also,
> only certain
> priviliged tasks execute as root. Ignore that this
The problem with priviliged tasks is that (in general)
they run with absolute privilige. Sure, some of these
priviliges can be turned off, but if /dev/mem is
reachable, then they can be turned back on again,
precicely for the reasons you give.
I guess that my understanding for having kernels the
size and complexity of Linux, as opposed to, say,
CP/M, is that the kernel can reduce the need for
userspace apps to have dangerous powers.
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
On Tue, 18 Jun 2002, Myrddin Ambrosius wrote:
>
> I guess that my understanding for having kernels the
> size and complexity of Linux, as opposed to, say,
> CP/M, is that the kernel can reduce the need for
> userspace apps to have dangerous powers.
Users need to have 'dangerous' things done, like reading and
writing to hard-disks, etc. To keep things organized, like
writing and reading files they control, there is some code
called the kernel, that performs these 'dangerous' things on
behalf of the callers. Since the callers can't modify the kernel
to make it do "bad" things like writing outside "files", everything
works out just fine. The exact same things can usually be done by
"user-mode" programs. You just need to keep them from being hacked and
everything works out just fine, just like in the kernel.
Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
Windows-2000/Professional isn't.
At 11:35 AM 6/18/2002 -0700, Myrddin Ambrosius wrote:
>The problem with priviliged tasks is that (in general)
>they run with absolute privilige. Sure, some of these
>priviliges can be turned off, but if /dev/mem is
>reachable, then they can be turned back on again,
>precicely for the reasons you give.
What about the bagels? I like bagels! ;)
I agree that this is a problem. A very, very good example of this is 'binding to a reserved port (<1024)'. A number of programs that should never need to run as root, do, some for the sole purpose of binding to a "reserved port":
* Webservers in a relatively simple configuration (ex: my Apache install)
* BIND (which doesn't even drop root. A security nightmare.)
* identd
There are kernel patches that can help solve this problem. One, found at ftp://ftp.v-lo.krakow.pl/pub/linux/patches/, creates 'magic' GIDs that give special limited privileges like binding to a reserved port (above list) or creating a raw socket (ping, traceroute).
If I recall the Capabilities FAQ correctly, I think there's something relating to PAM that might let you give partial capabilities to certain users who login (like CAP_SYS_TIME to your normal desktop login, so you can set the clock without using 'su'). It would be nice to be able to (relatively easily) create certain uids/gids (or names) that get special privileges automatically... then certain apps (like ping, traceroute) could be setuid something-less-powerful-than-root. I think that'd be an interesting project to work on when I'm bored... anybody on this list think it's worthy of discussion (or not worthy -- arguing is fun, it makes for more active threads!) ?
Just remember -- we need root/uid0/whatever, because in the end, the computers are here to serve US, to do OUR bidding. And using root is what I like to term an 'executive override' -- it cuts through all the protections and guards that the kernel has, and makes the computer do what we say. That's why we don't protect root from itself.
--
Stevie-O
Real programmers use COPY CON PROGRAM.EXE