Re: Cleaning out unneeded executables
- From: "shrike@xxxxxxxxxxxxxx" <shrike@xxxxxxxxxxxxxx>
- Date: 9 Sep 2006 19:01:44 -0700
Ertugrul Soeylemez wrote:
"shrike@xxxxxxxxxxxxxx" <shrike@xxxxxxxxxxxxxx> (06-08-16 12:12:12):
IMHO what is really needed is security down at the malloc() and
hardware level.
What do you mean by security at the malloc() level? What additional
security features could you add there? Protecting malloc()ed memory
from other processes and disabling code execution should be already
about everything possible at this place.
Doing memory allocation in hardware would prevent kernel hacks from
hiding things. If you could get a a picture of the memory allocated to
processes from hardware, then you could have a reliable means of
checking for rogue processes. People could mess with the Kernel all
they wanted, but if I can upload a binary that can query the bus and
thereby the memory allocation table directly, then I have a reliable
and simple way for checking whether a system is compromised.
I'm suprised somebody like Sun or AMD haven't gone completely back to
the drawing board and come up with a parallel processing architecture
optimized for security.
Well, that's a matter of view. IMO, the hardware should be as simple as
possible, and the software should provide security instead. The
hardware should only provide, what is needed for the software to
actually _enforce_ security policies.
On a typical linux box how many indevidual processes need the full
processing power of the CPU? If you had say 50 x 40Mhz chips side by
side each with physically independent block of memory, then you could
run 50 processes on indevidual chips.
You have an ASIC on the bus that provides piping between processes.
That ASIC would allow you to explicitly restrict certain processes
from network communication or from chaining to any process connected to
a socket. So you could impliment policies like: kernel modules are only
loadable from a process connected to the console port.
If it were the other way round: How would you handle a hardware bug?
Buying new hardware? Correcting the hardware yourself?
Buy new! Sure! I could see a PC that is basically a bunch of thumb
drives snapped into a backplane. Each drive is a PC-on-a-chip. The
backplane is a bus with inter-slot authentication. Essentially you've
got a cluster of 50 DOS boxes, with a central OS primarily functioning
to allocate time on the network interface cards.
Your security policy chips could also be replacable in a similar
fashion, allowing new feature revisions etc.
Of course this might suck for certain applications, but you could see
the vendors making Game versions of the processor modules for
excellerated graphics etc.
I'd rather swap a card than recompile and test a kernel.
Why do interprocess security in the kernel if you can run each process
on isolated hardware and stick an ASIC between them to do
authentication? Then you'd be able to ACL every PID.
Because different operating systems use different security models. You
would be limited to the facilities provided by the hardware.
Regards,
E.S.
Yes, different OS's use different security architectures, but I'm not
confident that that would prevent low level security features available
in hardware from benefiting any or all of them. To take full advantage
would probably require completely redesigning the kernel, while limited
advantage could be achieved by simply writing a driver. Sortof a
chroot() that is managed by hardware.
Dunno. It was just a thought.
Psy
.
- Prev by Date: Re: Qns on linux security frm windows users :::Help !!!
- Next by Date: Re: NSA wiretap, Friday night
- Previous by thread: THERE ARE REALLY NO SECURITY PRODUCTS
- Next by thread: Re: root:nobody in logs
- Index(es):
Relevant Pages
|
|
