In <000801bfba00$7bf42f30$1f0201c0@lw100> Ron Van Dam (rvandam@liwave.com) wrote:
>>> IP> A very better idea is to secure programs, and avoid programs running
RD> as
>>> IP> root.
>>>
>>> In ideal world - yes. In real world it does not work: programs are
RD> created
>>> by humans and thus holes are inavoidable in programs of decent size.
>>I rather have a hole in my non-user running app then in some app that runs
>>as root..
RD> Is there any way to compromise root, via a buffer overflow or some other
RD> means, even if the application using a non-previleged user id? Aren't there
RD> situations where running a userland daemon requires root access.
VERY rare.
RD> For instance, arpd or a routing daemon (routed, gated) that needs be able
RD> to write settings into the kernel?
They DO NOT need ability to change any part of kernel. They need exactly what
they need: ability to change tables in kernel.
RD> Is it possible to configure the Linux kernel so that it is secure.
Not yet.
RD> If so, what are your thoughts about including a configure option
RD> "make config" to secure the kernel.
It's big project. You need to carefully review all suser() checks/CAPABILITIES
checks in kernel and then add option "uid 0 is not special".
RD> So that unsecure functions were disabled when runnning in mult-user mode?
echo to /proc/sys/kernel/cap-bound is too hard for you ?
RD> I understand this would break some userland apps (X, multimedia apps, etc).
RD> However If your setting up a linux box as a firewall or web server or a box
RD> that needs to very secure, I don't think these type of apps would be
RD> installed anyway. Would there be really any need for direct
RD> hardware access for a box serving as a firewall or Web server?
God knows. Close it and see (do not try to write 0 in there -- this will
remove all power from root so on reboot even unmount will fail)...
RD> Would a "Sercure Kernel" compile option be an acceptable solution/compromise
RD> to this issue?
No need for "Secure Kernel" option. You can just add 1 (one) echo command
to startup scripts. If you need "Trusted Linux" it's still distant future
(not only kernel should be changed - you need LOTS of small tweaks in userland).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon May 15 2000 - 21:00:15 EST