Hi,
I'm concerned about the default behaviour of mounting encrypted volumes.
The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume.
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085
I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box.
Thoughts?
On 10/25/2010 04:28 PM, nodata wrote:
Hi,
I'm concerned about the default behaviour of mounting encrypted volumes.
The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume.
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085
I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box.
Wouldn't they be restricted based on the contents of the encrypted volume?
On 26/10/10 00:31, Nathanael D. Noblet wrote:
On 10/25/2010 04:28 PM, nodata wrote:
Hi,
I'm concerned about the default behaviour of mounting encrypted volumes.
The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume.
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085
I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box.
Wouldn't they be restricted based on the contents of the encrypted volume?
What do you mean?
On 26/10/10 00:31, Nathanael D. Noblet wrote:
On 10/25/2010 04:28 PM, nodata wrote:
Hi,
I'm concerned about the default behaviour of mounting encrypted volumes.
The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume.
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085
I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box.
Wouldn't they be restricted based on the contents of the encrypted volume?
Yes. Once the volume is mounted it will be treated with normal UNIX permissions. So you would have to create a sub-directory on the volume where the permissions were strict and create files under that.
My point is that if the disk is encrypted, and the user knows the passphrase to access files on the device, then it doesn't make sense to let everyone else see what's on the device as well: it only make sense to decrypt the device to the user who knows the passphrase.
There's an argument that other people will want to see what's on the device too. That's fine: the user can opt-in to that. But secure by default should be what we're aiming at.
On 10/25/2010 04:40 PM, nodata wrote:
Wouldn't they be restricted based on the contents of the encrypted volume?
Yes. Once the volume is mounted it will be treated with normal UNIX permissions. So you would have to create a sub-directory on the volume where the permissions were strict and create files under that.
My point is that if the disk is encrypted, and the user knows the passphrase to access files on the device, then it doesn't make sense to let everyone else see what's on the device as well: it only make sense to decrypt the device to the user who knows the passphrase.
There's an argument that other people will want to see what's on the device too. That's fine: the user can opt-in to that. But secure by default should be what we're aiming at.
I encrypt /home... So for my use case it doesn't make much sense. I guess I can see the case where you have some random storage that is encrypted, however I'm not sure how common this is, and file permissions keeps them at bay once mounted anyway. I guess if they could get root, once you decrypt they have access, but if they have root... you've got other problems.
On Tue, Oct 26, 2010 at 00:40:41 +0200, nodata lsof@nodata.co.uk wrote:
My point is that if the disk is encrypted, and the user knows the passphrase to access files on the device, then it doesn't make sense to let everyone else see what's on the device as well: it only make sense to decrypt the device to the user who knows the passphrase.
The files aren't decrypted to people (at least not yet, but expect a law requiring people to replace their eyes with ones that respect DRM sometime in the future). Once the OS can access the files, you are relying on the OS' security.
There's an argument that other people will want to see what's on the device too. That's fine: the user can opt-in to that. But secure by default should be what we're aiming at.
When you mount the file you can attach selinux context to all of the files or set the uid and group ownership to allow the OS to restrict access to the files excepting a compromised system or the use doing something boenheaded. (selinux can make the latter hard to do).
On 10/25/2010 06:40 PM, nodata wrote:
On 26/10/10 00:31, Nathanael D. Noblet wrote:
On 10/25/2010 04:28 PM, nodata wrote:
Hi,
I'm concerned about the default behaviour of mounting encrypted volumes.
The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume.
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
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.
On Tue, Oct 26, 2010 at 2:18 PM, Przemek Klosowski przemek.klosowski@nist.gov 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.
On 10/26/2010 01:03 PM, Gregory Maxwell wrote:
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.
Just out of curiosity... when are these being mounted? If we are talking about mounting a partition from a user session that's one thing and can easily make it user only accessible with a checkbox I guess. I'm wondering though, when you plug in a USB thumbdrive... don't all users have access? What's the difference here? Are we talking about system wide mounts like mine where only /home is encrypted??
Just wondering.
On Tue, Oct 26, 2010 at 13:16:41 -0600, "Nathanael D. Noblet" nathanael@gnat.ca wrote:
Just out of curiosity... when are these being mounted? If we are talking about mounting a partition from a user session that's one thing and can easily make it user only accessible with a checkbox I guess. I'm wondering though, when you plug in a USB thumbdrive... don't all users have access? What's the difference here? Are we talking about system wide mounts like mine where only /home is encrypted??
This is where we should be going. Encryption is really irrelavent. The issue should be if a removable device is inserted, who should have access to it if it gets automounted. I would expect encrypted and unencrypted devices to get the same treatment. The encrypted devices do already have a pop up, so maybe that makes it not as much effort to ask a question when the device is mounted. But I don't see otherwise why one would want to treat encrypted and uncrypted removable devices differently.
On Tue, Oct 26, 2010 at 4:10 PM, Bruno Wolff III bruno@wolff.to wrote:
This is where we should be going. Encryption is really irrelavent. The issue should be if a removable device is inserted, who should have access to it if it gets automounted. I would expect encrypted and unencrypted devices to get the same treatment. The encrypted devices do already have a pop up, so maybe that makes it not as much effort to ask a question when the device is mounted. But I don't see otherwise why one would want to treat encrypted and uncrypted removable devices differently.
We don't know which of multiple users plugged the device in but we know which user provided the key to decrypt the device.
The existence of encryption shows that the user may care more about the confidentiality of the data, and there is less of an previously existing "installed base" of expectations about how an encrypted volume works when you plug it in.
If we wanted to get fancy (e.g. go beyond just a change in the default modes) additional users could authenticate themselves to an already mounted encrypted volume one at a time by providing the key.
::shrugs::
On 26/10/10 22:24, Gregory Maxwell wrote:
On Tue, Oct 26, 2010 at 4:10 PM, Bruno Wolff IIIbruno@wolff.to wrote:
This is where we should be going. Encryption is really irrelavent. The issue should be if a removable device is inserted, who should have access to it if it gets automounted. I would expect encrypted and unencrypted devices to get the same treatment. The encrypted devices do already have a pop up, so maybe that makes it not as much effort to ask a question when the device is mounted. But I don't see otherwise why one would want to treat encrypted and uncrypted removable devices differently.
We don't know which of multiple users plugged the device in but we know which user provided the key to decrypt the device.
The existence of encryption shows that the user may care more about the confidentiality of the data, and there is less of an previously existing "installed base" of expectations about how an encrypted volume works when you plug it in.
This is exactly it.
If we wanted to get fancy (e.g. go beyond just a change in the default modes) additional users could authenticate themselves to an already mounted encrypted volume one at a time by providing the key.
::shrugs::
On Tue, 2010-10-26 at 15:10 -0500, Bruno Wolff III wrote:
On Tue, Oct 26, 2010 at 13:16:41 -0600, "Nathanael D. Noblet" nathanael@gnat.ca wrote:
Just out of curiosity... when are these being mounted? If we are talking about mounting a partition from a user session that's one thing and can easily make it user only accessible with a checkbox I guess. I'm wondering though, when you plug in a USB thumbdrive... don't all users have access? What's the difference here? Are we talking about system wide mounts like mine where only /home is encrypted??
This is where we should be going. Encryption is really irrelavent.
Not necessarily. There's a case that the automount behaviour for an encrypted volume should be different from that of a non-encrypted volume. As I read it, it's also technically plausible, because you can know with 100% accuracy which user should have access to the encrypted volume - the user from whose session the passphrase was entered. This is not the case with unencrypted volumes.
The issue should be if a removable device is inserted, who should have access to it if it gets automounted. I would expect encrypted and unencrypted devices to get the same treatment. The encrypted devices do already have a pop up, so maybe that makes it not as much effort to ask a question when the device is mounted. But I don't see otherwise why one would want to treat encrypted and uncrypted removable devices differently.
There's a technical issue; see above. And I can see a reasonable user expectation that on a multi-user system an encrypted volume should be mounted accessible only to the user who entered the passphrase, to be honest.
On Tue, Oct 26, 2010 at 14:18:55 -0400, Przemek Klosowski przemek.klosowski@nist.gov wrote:
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".
That's overstating things a bit. A root compromise is usually going to allow working around selinux limitations.
On 10/26/2010 04:05 PM, Bruno Wolff III wrote:
On Tue, Oct 26, 2010 at 14:18:55 -0400, Przemek Klosowskiprzemek.klosowski@nist.gov wrote:
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".
That's overstating things a bit. A root compromise is usually going to allow working around selinux limitations.
My point here is to distinguish between 'compromised root' and 'compromised overall system integrity'. Many (but not all) exploits are of the first kind (get a root shell, or change your EUID to zero). Of course the latter exploits can get around any security, as you say.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/26/2010 01:05 PM, Bruno Wolff III wrote:
On Tue, Oct 26, 2010 at 14:18:55 -0400, Przemek Klosowski przemek.klosowski@nist.gov wrote:
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".
That's overstating things a bit. A root compromise is usually going to allow working around selinux limitations.
That's only if you give root the right to disable or load new selinux policy.
Seriously, there are machines on the public Internet with a published root account. You're welcome to log in and try to do anything with them.
- -- Jesse Keating Fedora -- Freedom² is a feature! identi.ca: http://identi.ca/jkeating
On Tue, Oct 26, 2010 at 14:07:53 -0700, Jesse Keating jkeating@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE-----
That's only if you give root the right to disable or load new selinux policy.
And the policy is tight enough. You need to not allow root shells or most processes the ability to read the keys out of memory or to write memory that will change how things work. I don't think targeted policy is locked down enough to stop that even if you don't allow root to disble selinux.
Seriously, there are machines on the public Internet with a published root account. You're welcome to log in and try to do anything with them.
Yeah, I know about one guy that offers a root password if you ask. I am not sure what policy he is running on that machine.
On 10/26/2010 10:39 PM, Bruno Wolff III wrote:
On Tue, Oct 26, 2010 at 14:07:53 -0700, Jesse Keating jkeating@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE-----
That's only if you give root the right to disable or load new selinux policy.
And the policy is tight enough. You need to not allow root shells or most processes the ability to read the keys out of memory or to write memory that will change how things work. I don't think targeted policy is locked down enough to stop that even if you don't allow root to disble selinux.
Seriously, there are machines on the public Internet with a published root account. You're welcome to log in and try to do anything with them.
Yeah, I know about one guy that offers a root password if you ask. I am not sure what policy he is running on that machine.
It's Russell Coker, access details are available here:
http://www.coker.com.au/selinux/play.html
However the pages haven't been updated in a while and the service seems to be down right now.
Regards, Bryn.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/27/2010 06:35 AM, Bryn M. Reeves wrote:
On 10/26/2010 10:39 PM, Bruno Wolff III wrote:
On Tue, Oct 26, 2010 at 14:07:53 -0700, Jesse Keating jkeating@redhat.com wrote:
-----BEGIN PGP SIGNED MESSAGE-----
That's only if you give root the right to disable or load new selinux policy.
And the policy is tight enough. You need to not allow root shells or most processes the ability to read the keys out of memory or to write memory that will change how things work. I don't think targeted policy is locked down enough to stop that even if you don't allow root to disble selinux.
Seriously, there are machines on the public Internet with a published root account. You're welcome to log in and try to do anything with them.
Yeah, I know about one guy that offers a root password if you ask. I am not sure what policy he is running on that machine.
It's Russell Coker, access details are available here:
http://www.coker.com.au/selinux/play.html
However the pages haven't been updated in a while and the service seems to be down right now.
Regards, Bryn.
There are two ways to get root on a system. One is through a login process. Either login directly as root or login as a user and execute su/sudo. SELinux by default since F9 and RHEL6 allows you to setup confined users, but defaults to unconfined_t. If you login to a system as a user and get unconfined_t user type, and you become root, you can take over the system. You can setup the root account to login as any confined user, and show a UID=0 account that can not do much.
SELinux also includes the concept of confined admin. You can setup accounts that have limited privledged root access. webadm_r:webadm_t
http://magazine.redhat.com/2008/04/17/fedora-9-and-summit-preview-confining-...
Explains this.
On my laptop I run as staff_t and when I run sudo I become webadm_t. If I run runuser I become unconfined_t. This means you can setup a user account that can use sudo to do certain admin activities with locked down privs.
The other way you can become root is to break into the system through a flaw in a network service. If you are running SELinux and break into httpd, you would endup with a process labeled httpd_t, and would only be allowed to do the things the web server is allowed to do, even if your UID==0.
One caveat in this is, if there is a kernel flaw that allows a account to manipulate memory in the kernel, the hacker has a chance to turn SELinux enforcement off, and all bets are off. We try to protect against this through checks like execmem,execstack,execmod,execheap and memzero checks. Hopefully more in the future.
nodata wrote:
Hi,
I'm concerned about the default behaviour of mounting encrypted volumes.
The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume.
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085
I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box.
Thoughts?
If you want something closer to per-file encryption, try out ecryptfs.
http://ecryptfs.sourceforge.net/ecryptfs-faq.html#compare
-Eric
On Tue, 2010-10-26 at 00:28 +0200, nodata wrote:
Hi,
I'm concerned about the default behaviour of mounting encrypted volumes.
The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume.
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085
I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box.
Thoughts?
I'd think you mixed the concept of volume encryption and permission. Once you supply the pass for the encrypted volume, it means that you grant the right to OS to mount this volume. Then the OS is in charge of permission settings. OS doesn't care about if it is encrypted or not, it only knows some volume wants to be mounted and it sets permission as the default schema.
Qiang
On 26/10/10 07:05, Qiang Li wrote:
On Tue, 2010-10-26 at 00:28 +0200, nodata wrote:
Hi,
I'm concerned about the default behaviour of mounting encrypted volumes.
The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume.
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085
I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box.
Thoughts?
I'd think you mixed the concept of volume encryption and permission. Once you supply the pass for the encrypted volume, it means that you grant the right to OS to mount this volume. Then the OS is in charge of permission settings. OS doesn't care about if it is encrypted or not, it only knows some volume wants to be mounted and it sets permission as the default schema.
Qiang
Imagine that you want to login to the computer, your username is oiang. I want to login too. My username is nodata. Now, I can only login to my account and look at my files because only I know my password. You can only login to your account because only you know your password.
Now imagine if you could read all of _my_ files and I could read all of yours. That makes no sense. You _can_ configure that if you want, but by default we go for security.
This is the same. You connect your encrypted hard disk to the system and you can look at the files on it because you know the passphrase.
The fix to make this work is a 750 mode on /media/VOLUME-NAME
On Tue, Oct 26, 2010 at 12:07:56 +0200, nodata lsof@nodata.co.uk wrote:
Now imagine if you could read all of _my_ files and I could read all of yours. That makes no sense. You _can_ configure that if you want, but by default we go for security.
Once upon a time that was the default for systems.
This is the same. You connect your encrypted hard disk to the system and you can look at the files on it because you know the passphrase.
That is muddy thinking. The OS needs the password, you can't directly look at the disk using the password in your head. The OS needs to manage access to the encrypted device.
The fix to make this work is a 750 mode on /media/VOLUME-NAME
I'd surely suggest using 0700 instead of 0750 given your concerns about other people being able to access the contents.
Using selinux provides a way to limit accidental leaking in some circumstances and may be a better approach if you have time to do the upfront work.
On 26/10/10 16:00, Bruno Wolff III wrote:
On Tue, Oct 26, 2010 at 12:07:56 +0200, nodatalsof@nodata.co.uk wrote:
Now imagine if you could read all of _my_ files and I could read all of yours. That makes no sense. You _can_ configure that if you want, but by default we go for security.
Once upon a time that was the default for systems.
This is the same. You connect your encrypted hard disk to the system and you can look at the files on it because you know the passphrase.
That is muddy thinking. The OS needs the password, you can't directly look at the disk using the password in your head. The OS needs to manage access to the encrypted device.
I don't really understand what you're trying to say here.
A person who knows the passphrase and nobody else (apart from super users, the kernel, etc) should be the only one who can access the unencrypted device.
The fix to make this work is a 750 mode on /media/VOLUME-NAME
I'd surely suggest using 0700 instead of 0750 given your concerns about other people being able to access the contents.
Using selinux provides a way to limit accidental leaking in some circumstances and may be a better approach if you have time to do the upfront work.
On Tue, Oct 26, 2010 at 16:56:41 +0200, nodata lsof@nodata.co.uk wrote:
On 26/10/10 16:00, Bruno Wolff III wrote:
On Tue, Oct 26, 2010 at 12:07:56 +0200, nodatalsof@nodata.co.uk wrote:
Now imagine if you could read all of _my_ files and I could read all of yours. That makes no sense. You _can_ configure that if you want, but by default we go for security.
Once upon a time that was the default for systems.
This is the same. You connect your encrypted hard disk to the system and you can look at the files on it because you know the passphrase.
That is muddy thinking. The OS needs the password, you can't directly look at the disk using the password in your head. The OS needs to manage access to the encrypted device.
I don't really understand what you're trying to say here.
A person who knows the passphrase and nobody else (apart from super users, the kernel, etc) should be the only one who can access the unencrypted device.
How do you expect this to happen? The user is going to supply the password to the OS and it is going to access the volume. At that point the OS is protecting the data from unauthorized use by other users, not a password. So you need to use normal OS controls on this.
The feature you seem to be looking for is that when an encrypted device is mounted, that there be different defaults than when automounting unencrypted devices. That might be reasonable (depending on what the defaults are).
If the device has an ext* file system on it, normal uid usage should be good enough if you just use it on one system or accross a set where you have the same uid.
You can also use /etc/fstab to automatically control how the device is mounted.
On 10/26/2010 04:07 AM, nodata wrote:
Imagine that you want to login to the computer, your username is oiang. I want to login too. My username is nodata. Now, I can only login to my account and look at my files because only I know my password. You can only login to your account because only you know your password.
Now imagine if you could read all of _my_ files and I could read all of yours. That makes no sense. You _can_ configure that if you want, but by default we go for security.
This is the same. You connect your encrypted hard disk to the system and you can look at the files on it because you know the passphrase.
The fix to make this work is a 750 mode on /media/VOLUME-NAME
Just to clarify, your encrypted disk is external? Like a USB or eSATA drive? Also I'm curious, if you plugged in a USB thumbdrive (without encryption) does it not allow everyone (with permissions) to view ? I'm not disagreeing with you regarding your use case, just trying to understand it better....
On Tue, 2010-10-26 at 00:28 +0200, nodata wrote:
Hi,
I'm concerned about the default behaviour of mounting encrypted volumes.
The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume.
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085
I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box.
Thoughts?
This could be achieved by using pam_namespace to separate the namespaces of the logged-in users and mounting the encrypted volume as private into the namespace. However it also means that when the user is simultaneously logged in twice, he will not be able to access the encrypted volume in the second session either. It also means that the process that mounts the volume must run in the namespace of the user's session (setuid helper would be needed instead of using system service to mount the volume).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/26/2010 02:36 AM, Tomas Mraz wrote:
On Tue, 2010-10-26 at 00:28 +0200, nodata wrote:
Hi,
I'm concerned about the default behaviour of mounting encrypted volumes.
The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume.
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
I've filed a bug about this, and it got closed: https://bugzilla.redhat.com/show_bug.cgi?id=646085
I'm quite in favour of secure by default. In the worst case, the mountpoint would have permissions set to read access to all if you tick a box.
Thoughts?
This could be achieved by using pam_namespace to separate the namespaces of the logged-in users and mounting the encrypted volume as private into the namespace. However it also means that when the user is simultaneously logged in twice, he will not be able to access the encrypted volume in the second session either. It also means that the process that mounts the volume must run in the namespace of the user's session (setuid helper would be needed instead of using system service to mount the volume).
Might be something we could add to seunshare?
On 10/26/2010 09:44 AM, Matthew Garrett wrote:
On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote:
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
Only if the permissions are set that way. chmod 0750 /whatever and it won't be.
I think that the concern is correct and valid - using encrypted block devices with a mount time password is quite "weak" for system security in general, it is just the easiest way to provide basic crypto. Much better suited for laptops than servers where any root user would be able to peruse the mounted volume's contents.
There are a host of other ways to do this though - ecryptfs (as Eric Sandeen mentioned) does finer grained crypto (even though we are not huge fans of how its design) and you can certainly encrypt files individually.
Ric
On 10/26/2010 02:44 PM, Matthew Garrett wrote:
On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote:
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
Only if the permissions are set that way. chmod 0750 /whatever and it won't be.
On my system an auto-mounted exchangeable volume always seems to be 0700.
Andrew.
On 26/10/10 16:11, Andrew Haley wrote:
On 10/26/2010 02:44 PM, Matthew Garrett wrote:
On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote:
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
Only if the permissions are set that way. chmod 0750 /whatever and it won't be.
On my system an auto-mounted exchangeable volume always seems to be 0700.
Andrew.
Really? Any chance of a copy-paste?
This is what I get:
$ ls -la /media/ total 12 drwxr-xr-x. 3 root root 4096 Oct 26 16:51 . dr-xr-xr-x. 24 root root 4096 Oct 26 16:51 .. drwxr-xr-x. 4 root root 4096 Oct 23 17:40 WESTERNDIGITAL
On 10/26/2010 03:57 PM, nodata wrote:
On 26/10/10 16:11, Andrew Haley wrote:
On 10/26/2010 02:44 PM, Matthew Garrett wrote:
On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote:
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
Only if the permissions are set that way. chmod 0750 /whatever and it won't be.
On my system an auto-mounted exchangeable volume always seems to be 0700.
Andrew.
Really? Any chance of a copy-paste?
This is what I get:
$ ls -la /media/ total 12 drwxr-xr-x. 3 root root 4096 Oct 26 16:51 . dr-xr-xr-x. 24 root root 4096 Oct 26 16:51 .. drwxr-xr-x. 4 root root 4096 Oct 23 17:40 WESTERNDIGITAL
Exactly. It is 0755.
On 10/26/2010 05:14 PM, Vaclav Mocek wrote:
On 10/26/2010 03:57 PM, nodata wrote:
On 26/10/10 16:11, Andrew Haley wrote:
On 10/26/2010 02:44 PM, Matthew Garrett wrote:
On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote:
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
Only if the permissions are set that way. chmod 0750 /whatever and it won't be.
On my system an auto-mounted exchangeable volume always seems to be 0700.
Really? Any chance of a copy-paste?
This is what I get:
$ ls -la /media/ total 12 drwxr-xr-x. 3 root root 4096 Oct 26 16:51 . dr-xr-xr-x. 24 root root 4096 Oct 26 16:51 .. drwxr-xr-x. 4 root root 4096 Oct 23 17:40 WESTERNDIGITAL
Exactly. It is 0755.
$ ls -la /media total 16 drwxr-xr-x. 3 root root 4096 2010-10-26 17:56 ./ dr-xr-xr-x. 28 root root 4096 2010-09-16 04:24 ../ drwx------. 2 aph aph 8192 1970-01-01 01:00 C0C1-215C/
Ahh, I think I may know why: it's a DOS filesystem. Sorry for the noise.
And yes, I agree. 0755 makes no sense to me.
Andrew.
On Tue, Oct 26, 2010 at 12:28:55AM +0200, nodata wrote:
The default behaviour is that a user must know and supply a passphrase in order to mount an encrypted volume. This is good: know the passphrase, you get to mount the volume.
What I am concerned about is that the volume is mounted for _every_ user on the system to see.
Another option is guestfish which has LUKS support now (in Fedora 14).
This works because guestfish runs another Linux kernel as the local user, and you only pass the key to that kernel. The normal user separation of Linux prevents another non-root user from gaining access to the key.
As with all of the schemes discussed, root on the machine would still be able to gain access. Local non-root users could also try their hand at exploiting the host kernel -- usually easier to do than a remote exploit -- or looking for some side channel such as keys being leaked through process arguments. Local users + super-secret data is not a great recipe for assured security.
Rich.
$ guestfish --ro -a F13x64Encrypted.img
Welcome to guestfish, the libguestfs filesystem interactive shell for editing virtual machine filesystems.
Type: 'help' for a list of commands 'man' to read the manual 'quit' to quit the shell
<fs> run <fs> list-partitions
/dev/vda1 /dev/vda2
<fs> luks-open /dev/sda2 encrypted
Enter key or passphrase ("key"):
<fs> vgscan <fs> vg-activate true "" <fs> lvs
/dev/vg_f13x64encrypted/lv_root /dev/vg_f13x64encrypted/lv_swap
<fs> mount-options "" /dev/vg_f13x64encrypted/lv_root / <fs> ll /home/
total 12 drwxr-xr-x. 3 root root 4096 Jul 21 12:00 . dr-xr-xr-x. 24 root root 4096 Jul 21 12:01 .. drwx------. 4 500 500 4096 Jul 21 12:00 rjones