-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 wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>>
>>> That's only if you give root the right t
On 10/26/2010 10:39 PM, Bruno Wolff III wrote:
> On Tue, Oct 26, 2010 at 14:07:53 -0700,
> Jesse Keating 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
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" 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
> > e
On Tue, Oct 26, 2010 at 14:07:53 -0700,
Jesse Keating 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
On 26/10/10 22:24, Gregory Maxwell wrote:
> On Tue, Oct 26, 2010 at 4:10 PM, Bruno Wolff III 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
On 10/26/2010 04:05 PM, Bruno Wolff III wrote:
> On Tue, Oct 26, 2010 at 14:18:55 -0400,
>Przemek Klosowski 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
-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 wrote:
>>
>> Such user-differentiated authorization is provided by the filesystem
>> access rights, ACLs and SELinux attributes. Note that
On Tue, Oct 26, 2010 at 4:10 PM, Bruno Wolff III 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
On Tue, Oct 26, 2010 at 13:16:41 -0600,
"Nathanael D. Noblet" 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
> won
On Tue, Oct 26, 2010 at 14:18:55 -0400,
Przemek Klosowski 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
> compromise
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
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 pass
On Tue, Oct 26, 2010 at 2:18 PM, Przemek Klosowski
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
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
>>>
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
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 Tue, Oct 26, 2010 at 16:56:41 +0200,
nodata wrote:
> On 26/10/10 16:00, Bruno Wolff III wrote:
> > On Tue, Oct 26, 2010 at 12:07:56 +0200,
> >nodata wrote:
> >>
> >> Now imagine if you could read all of _my_ files and I could read all of
> >> yours. That makes no sense. You _can_ configu
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
On 26/10/10 16:00, Bruno Wolff III wrote:
> On Tue, Oct 26, 2010 at 12:07:56 +0200,
>nodata 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 u
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
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 Tue, Oct 26, 2010 at 12:07:56 +0200,
nodata 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.
> Thi
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
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.
--
Matthew Garrett | mj...@srcf.ucam.org
--
devel mailing
-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 passph
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
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 t
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
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 c
On Tue, Oct 26, 2010 at 00:40:41 +0200,
nodata 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 devi
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 a
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
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
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 volu
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 volum
35 matches
Mail list logo
