On Thu, Jan 1, 2009 at 3:09 AM, Arjan van de Ven <arjan@xxxxxxxxxxxxx> wrote:
> On Wed, 31 Dec 2008 20:11:13 -0800 "Muntz, Daniel" <Dan.Muntz@xxxxxxxxxx> wrote:
>> If you're following the protocol, it doesn't even matter if a bad guy
>> ("untrusted user"?) gets root on the client--they still can't gain
>> inappropriate access to the file server. OTOH, if my security plan is
>> simply to not allow root access to untrusted users, history says I'm
>> going to lose.
>
> if you have a user, history says you're going to lose.
>
> you can make your system as secure as you want, with physical access
> all bets are off.
Yeah... this is precisely the reason that the security-test-plan and
system-design-document for any really security sensitive system starts
with:
[ ] The system is in a locked rack
[ ] The rack is in a locked server room with detailed access logs
[ ] The server room is in a locked and secured building with 24-hour
camera surveillance and armed guards
I've spent a little time looking into the security guarantees provided
by DAC and by the FS-Cache LSM hooks, and it is possible to reasonably
guarantee that no *REMOTE* user will be able to compromise the
contents of the cache using a combination of DAC (file permissions,
etc) and MAC (SELinux, etc) controls. As previously mentioned, local
users (with physical hardware access) are an entirely different story.
As far as performance considerations for the merge... FS-cache on
flash-based storage also has very different performance tradeoffs from
traditional rotating media. Specifically I have some sample 32GB
SATA-based flash media here with ~230Mbyte/sec sustained read and
~200Mbyte/sec sustained write and with a 75usec read latency. It
doesn't take much link latency at all to completely dwarf that kind of
access time.
Cheers,
Kyle Moffett
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
