FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

 
 
LinkBack Thread Tools
 
Old 10-25-2010, 10:28 PM
nodata
 
Default Mounting an encrypted volume presents the volume to all users on a machine

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?

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-26-2010, 01:54 AM
Bruno Wolff III
 
Default Mounting an encrypted volume presents the volume to all users on a machine

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).
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-26-2010, 02:00 PM
Bruno Wolff III
 
Default Mounting an encrypted volume presents the volume to all users on a machine

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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-26-2010, 02:51 PM
"Richard W.M. Jones"
 
Default Mounting an encrypted volume presents the volume to all users on a machine

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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-26-2010, 03:48 PM
Bruno Wolff III
 
Default Mounting an encrypted volume presents the volume to all users on a machine

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,
> > 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.
>
> 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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-26-2010, 07:03 PM
Gregory Maxwell
 
Default Mounting an encrypted volume presents the volume to all users on a machine

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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-26-2010, 08:05 PM
Bruno Wolff III
 
Default Mounting an encrypted volume presents the volume to all users on a machine

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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-26-2010, 08:10 PM
Bruno Wolff III
 
Default Mounting an encrypted volume presents the volume to all users on a machine

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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-26-2010, 08:24 PM
Gregory Maxwell
 
Default Mounting an encrypted volume presents the volume to all users on a machine

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::
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 
Old 10-26-2010, 09:39 PM
Bruno Wolff III
 
Default Mounting an encrypted volume presents the volume to all users on a machine

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.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
 

Thread Tools




All times are GMT. The time now is 12:21 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org