On Tue, Oct 26, 2010 at 2:18 PM, Przemek Klosowski <przemek.klosowski@xxxxxxxx> wrote: > The security role and rationale for the filesystem encryption is to > prevent the access to lost or stolen media, when you can't rely on the > mechanisms existent within the OS. The underlying device encryption > technology is not set up to keep track of who is accessing the data > after it is decrypted and made available to the system, as you correctly > point out. > > Such user-differentiated authorization is provided by the filesystem > access rights, ACLs and SELinux attributes. Note that unlike the first > two mechanisms, SELinux can protect the data even for systems with > compromised root---as someone said, SELinux can be configured so that > you can tell people "here's the root password; now break into my computer". > > What you are asking for improves security by adding additional depth, > but it requires a fairly intensive redesign and reimplementation of the > device encryption, so it befall on you to provide a good analysis and > justification of the tradeoffs. I don't think anyone here is asking for protection from root or anything as elaborate as a SELinux MLS configuration. I think that a small change in the default mount behavior so that the mountpoint encrypted is always owned by the user and mode 700â or if it were mounted under the user's home directory, perhaps with a checkbox (defaulting to off) on the password dialog "Make this volume available to all users on my system", would better meet the user's expectations of how an encrypted volume should behave. There are a lot of neat security things which could and should be done. Why can firefox upload my ssh private key file to random websites? Etc. But this case isn't one of those SELinux rocket science cases, it's simply a matter of using regular unix security in a way that reduces surprises. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
