On Tue, May 13, 2003 at 11:32:11AM +0530, Kamal R Prasad wrote:
> ------------------------------------------------------------------------------
> Kamal R. Prasad
> AIX Support & Test, IBM India Software Labs
> Golden Enclave, Airport Road, Bangalore-560017, India
> Phone : +91-80-5094963,  Internal Ext   : 2963
> 
> 
> 
> 
> >On Tue, May 13, 2003 at 10:22:12AM +0530, Kamal R Prasad wrote:
> >That doesn't make any sense at all.  How would a cryptographic filesystem
> >have helped any more than simply changing the permissions on the
> >binaries so that they were executable but not readable?
> 
> The kernel will have a key to decrypt binaries that are loaded from hard 
> disk. so copying the encrypted binaries on another unix box will not allow 
> them to be used.

That doesn't make any sense at all; if you can bypoass the kernel's
protection and copy executables that have executable but not read 
permission, you can bypass the kernel's protection and decrypt and
copy the executables.

> It did make sense to the developers -but I was not closely involved with 
> it and maybe cannot explain it to you properly.

I've seen an awful lot of otherwise sensible people turn to encryption
as some sort of magic security touchstone, never stopping to consider
that it's *what you use it for* and *how you use it* that matters; just
making calls to various encryption functions does *nothing* to enhance
system security; rather it just burns CPU time and can, in fact, get in
the way of a clear understanding of the actual security model and the
effectiveness of the taken to enforce it.  Hiding a decryption key in the
kernel and thinking that this is somehow better than just using filesystem
permissions to keep binaries from being read seems like a typical example
of this...

Thor