5:28 p.m.
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?
5:31 p.m.
New subject: Mounting an encrypted volume presents the volume to all users on a machine
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?
5:33 p.m.
New subject: Mounting an encrypted volume presents the volume to all users on a machine
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?
5:40 p.m.
New subject: Mounting an encrypted volume presents the volume to all users on a machine
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.
5:45 p.m.
New subject: Mounting an encrypted volume presents the volume to all users on a machine
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.
8:54 p.m.
On Tue, Oct 26, 2010 at 00:40:41 +0200,
nodata <lsof(a)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).
1:18 p.m.
New subject: Mounting an encrypted volume presents the volume to all users on a machine
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.
2:03 p.m.
On Tue, Oct 26, 2010 at 2:18 PM, Przemek Klosowski
<przemek.klosowski(a)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.
2:16 p.m.
New subject: Mounting an encrypted volume presents the volume to all users on a machine
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.
--
Nathanael d. Noblet
3:10 p.m.
On Tue, Oct 26, 2010 at 13:16:41 -0600,
"Nathanael D. Noblet" <nathanael(a)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.
3:24 p.m.
On Tue, Oct 26, 2010 at 4:10 PM, Bruno Wolff III <bruno(a)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::
4:16 p.m.
New subject: Mounting an encrypted volume presents the volume to all users on a machine
On 26/10/10 22:24, Gregory Maxwell wrote:
On Tue, Oct 26, 2010 at 4:10 PM, Bruno Wolff
III<bruno(a)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::
12:51 a.m.
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(a)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.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:05 p.m.
On Tue, Oct 26, 2010 at 14:18:55 -0400,
Przemek Klosowski <przemek.klosowski(a)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.
4:07 p.m.
New subject: Mounting an encrypted volume presents the volume to all users on a machine
On 10/26/2010 04:05 PM, Bruno Wolff III wrote:
On Tue, Oct 26, 2010 at 14:18:55 -0400,
Przemek Klosowski<przemek.klosowski(a)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.
4:07 p.m.
-----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(a)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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkzHQykACgkQ4v2HLvE71NWTLQCgqDG5fxdz5JIN9UHJgoKgjoTu
nqIAn36jkuXDvxah49dukTjQ2hWyj5+q
=TQbe
-----END PGP SIGNATURE-----
4:39 p.m.
On Tue, Oct 26, 2010 at 14:07:53 -0700,
Jesse Keating <jkeating(a)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.
5:35 a.m.
New subject: Mounting an encrypted volume presents the volume to all users on a 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(a)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.
8:07 a.m.
New subject: Mounting an encrypted volume presents the volume to all users on a machine
-----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(a)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-confini...
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkzIJCcACgkQrlYvE4MpobM0TwCggJGaDwUnUrVFsuQa2YSk74X1
MUYAni2CkV2vu1IsUraYtu5W7MNTbsBq
=rLD7
-----END PGP SIGNATURE-----
9:19 p.m.
New subject: Mounting an encrypted volume presents the volume to all users on a machine
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
12:05 a.m.
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
--
Qiang Li
HuBei Polytechnic Institute
No. 17 YuQuan Road
XiaoGan HuBei 432100
China
E-mail: liqiang(a)hbvtc.edu.cn
5:07 a.m.
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
9 a.m.
On Tue, Oct 26, 2010 at 12:07:56 +0200,
nodata <lsof(a)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.
9:56 a.m.
On 26/10/10 16:00, Bruno Wolff III wrote:
On Tue, Oct 26, 2010 at 12:07:56 +0200,
nodata<lsof(a)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.
10:48 a.m.
On Tue, Oct 26, 2010 at 16:56:41 +0200,
nodata <lsof(a)nodata.co.uk> wrote:
On 26/10/10 16:00, Bruno Wolff III wrote:
> On Tue, Oct 26, 2010 at 12:07:56 +0200,
> nodata<lsof(a)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.
2:18 p.m.
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....
1:36 a.m.
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).
--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
Turkish proverb
7:21 a.m.
-----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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAkzGx7QACgkQrlYvE4MpobNHaACgrpZOOlI7IRtgPFEImpQnNZBs
SNsAnRjAIRe9TJCg8NbA9hHOMcxrjiLr
=Kwo5
-----END PGP SIGNATURE-----
8:52 a.m.
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
9:11 a.m.
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.
9:57 a.m.
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
11:14 a.m.
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.
12:01 p.m.
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.
9:51 a.m.
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
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into Xen guests.
http://et.redhat.com/~rjones/virt-p2v
4990
days inactive
4992
days old
34 comments
17 participants
participants (17)
-
Adam Williamson -
Andrew Haley -
Bruno Wolff III -
Bryn M. Reeves -
Daniel J Walsh -
Eric Sandeen -
Gregory Maxwell -
Jesse Keating -
little.owl -
Matthew Garrett -
Nathanael D. Noblet -
nodata -
Przemek Klosowski -
Qiang Li -
Ric Wheeler -
Richard W.M. Jones -
Tomas Mraz