On Wed, Mar 13, 2019 at 11:42 PM Richard Weinberger wrote:
>
> Am Mittwoch, 13. März 2019, 23:26:11 CET schrieb Eric Biggers:
> > What specifically is wrong with supporting the ciphertext "view" of
> > encrypted
> > directories, and why do you want to opt UBIFS out of it specifically but not
> >
On Wed, Mar 13, 2019 at 03:29:43PM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 15:13 -0700, Eric Biggers wrote:
> > On Wed, Mar 13, 2019 at 02:04:29PM -0700, James Bottomley wrote:
> > > On Wed, 2019-03-13 at 13:25 -0700, Eric Biggers wrote:
> > > > On Wed, Mar 13, 2019 at 01:06:06PM -070
Am Mittwoch, 13. März 2019, 23:26:11 CET schrieb Eric Biggers:
> On Wed, Mar 13, 2019 at 09:33:10PM +0100, Richard Weinberger wrote:
> > Am Mittwoch, 13. März 2019, 15:26:54 CET schrieb Amir Goldstein:
> > > IMO, the best thing for UBIFS to do would be to modify fscrypt to support
> > > opting out
On Wed, 2019-03-13 at 15:13 -0700, Eric Biggers wrote:
> On Wed, Mar 13, 2019 at 02:04:29PM -0700, James Bottomley wrote:
> > On Wed, 2019-03-13 at 13:25 -0700, Eric Biggers wrote:
> > > On Wed, Mar 13, 2019 at 01:06:06PM -0700, James Bottomley wrote:
> > > > On Wed, 2019-03-13 at 12:57 -0700, Eric
On Wed, Mar 13, 2019 at 09:33:10PM +0100, Richard Weinberger wrote:
> Am Mittwoch, 13. März 2019, 15:26:54 CET schrieb Amir Goldstein:
> > IMO, the best thing for UBIFS to do would be to modify fscrypt to support
> > opting out of the revalidate behavior, IWO, sanitize your hack to an API.
>
> Giv
On Wed, Mar 13, 2019 at 02:04:29PM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 13:25 -0700, Eric Biggers wrote:
> > On Wed, Mar 13, 2019 at 01:06:06PM -0700, James Bottomley wrote:
> > > On Wed, 2019-03-13 at 12:57 -0700, Eric Biggers wrote:
> [...]
> > > > fscrypt would allow the data to
On Wed, 2019-03-13 at 13:25 -0700, Eric Biggers wrote:
> On Wed, Mar 13, 2019 at 01:06:06PM -0700, James Bottomley wrote:
> > On Wed, 2019-03-13 at 12:57 -0700, Eric Biggers wrote:
[...]
> > > fscrypt would allow the data to be stored encrypted on the local
> > > disk, so it's protected against off
Am Mittwoch, 13. März 2019, 15:26:54 CET schrieb Amir Goldstein:
> IMO, the best thing for UBIFS to do would be to modify fscrypt to support
> opting out of the revalidate behavior, IWO, sanitize your hack to an API.
Given the WTF/s rate this thread has, this might me a good option.
Actually peopl
On Wed, Mar 13, 2019 at 01:06:06PM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 12:57 -0700, Eric Biggers wrote:
> > On Wed, Mar 13, 2019 at 12:17:52PM -0700, James Bottomley wrote:
> > > On Wed, 2019-03-13 at 14:58 -0400, Theodore Ts'o wrote:
> > > > On Wed, Mar 13, 2019 at 10:45:04AM -07
On Wed, 2019-03-13 at 12:57 -0700, Eric Biggers wrote:
> On Wed, Mar 13, 2019 at 12:17:52PM -0700, James Bottomley wrote:
> > On Wed, 2019-03-13 at 14:58 -0400, Theodore Ts'o wrote:
> > > On Wed, Mar 13, 2019 at 10:45:04AM -0700, James Bottomley wrote:
> > > > > If they can't break root, then the
On Wed, Mar 13, 2019 at 12:17:52PM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 14:58 -0400, Theodore Ts'o wrote:
> > On Wed, Mar 13, 2019 at 10:45:04AM -0700, James Bottomley wrote:
> > > > If they can't break root, then the OS's user-id based access
> > > > control checks (or SELinux c
On Wed, Mar 13, 2019 at 07:19:46PM +, Al Viro wrote:
> On Wed, Mar 13, 2019 at 09:44:33AM -0700, Eric Biggers wrote:
>
> > > Just to make sure - you do realize that ban on multiple dentries refering
> > > to the same directory inode is *NOT* conditional upon those dentries being
> > > hashed,
On Wed, 2019-03-13 at 14:58 -0400, Theodore Ts'o wrote:
> On Wed, Mar 13, 2019 at 10:45:04AM -0700, James Bottomley wrote:
> > > If they can't break root, then the OS's user-id based access
> > > control checks (or SELinux checks if you are using SELinux) will
> > > still protect you.
> >
> > We
On Wed, Mar 13, 2019 at 09:44:33AM -0700, Eric Biggers wrote:
> > Just to make sure - you do realize that ban on multiple dentries refering
> > to the same directory inode is *NOT* conditional upon those dentries being
> > hashed, right?
>
> Isn't this handled by d_splice_alias() already, by movi
On Wed, Mar 13, 2019 at 10:45:04AM -0700, James Bottomley wrote:
> > If they can't break root, then the OS's user-id based access
> > control checks (or SELinux checks if you are using SELinux) will
> > still protect you.
>
> Well, that's what one would think about the recent runc exploit as
> w
On Wed, 2019-03-13 at 12:44 -0400, Theodore Ts'o wrote:
> On Wed, Mar 13, 2019 at 08:36:34AM -0700, James Bottomley wrote:
> > On Wed, 2019-03-13 at 11:16 -0400, Theodore Ts'o wrote:
> > > So before we talk about how to make things work from a technical
> > > perspective, we should consider what th
On Wed, Mar 13, 2019 at 08:36:34AM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 11:16 -0400, Theodore Ts'o wrote:
> > So before we talk about how to make things work from a technical
> > perspective, we should consider what the use case happens to be, and
> > what are the security requirem
On Wed, Mar 13, 2019 at 04:06:16PM +, Al Viro wrote:
> On Wed, Mar 13, 2019 at 11:16:33AM -0400, Theodore Ts'o wrote:
> > Actually, the original use was for ChromeOS, but the primary
> > assumption is that keying is per user (or profile), and that users are
> > mutually distrustful. So when Al
On Wed, Mar 13, 2019 at 04:11:48PM +, Al Viro wrote:
> On Wed, Mar 13, 2019 at 08:01:27AM -0700, Eric Biggers wrote:
>
> > What do you think about this?
>
> That fscrypt might have some very deep flaws. I'll need to RTFS and
> review its model, but what I've seen in this thread so far is not
Am Mittwoch, 13. März 2019, 17:13:52 CET schrieb James Bottomley:
> > What do you mean by "containment breaches by other tenants"? Note
> > that while the key is added, fscrypt doesn't prevent access to the
> > encrypted files.
>
> You mean it's not multiuser safe? Even if user a owns the key th
On Wed, 2019-03-13 at 08:51 -0700, Eric Biggers wrote:
> Hi James,
>
> On Wed, Mar 13, 2019 at 08:36:34AM -0700, James Bottomley wrote:
> > On Wed, 2019-03-13 at 11:16 -0400, Theodore Ts'o wrote:
> > > So before we talk about how to make things work from a technical
> > > perspective, we should co
On Wed, Mar 13, 2019 at 08:01:27AM -0700, Eric Biggers wrote:
> What do you think about this?
That fscrypt might have some very deep flaws. I'll need to RTFS and
review its model, but what I've seen in this thread so far is not
promising anything good.
It's not just overlayfs - there are all ki
On Wed, Mar 13, 2019 at 11:16:33AM -0400, Theodore Ts'o wrote:
> Actually, the original use was for ChromeOS, but the primary
> assumption is that keying is per user (or profile), and that users are
> mutually distrustful. So when Alice logs out of the system, her keys
> will be invalidated and re
Hi James,
On Wed, Mar 13, 2019 at 08:36:34AM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 11:16 -0400, Theodore Ts'o wrote:
> > So before we talk about how to make things work from a technical
> > perspective, we should consider what the use case happens to be, and
> > what are the securi
On Wed, 2019-03-13 at 11:16 -0400, Theodore Ts'o wrote:
> So before we talk about how to make things work from a technical
> perspective, we should consider what the use case happens to be, and
> what are the security requirements. *Why* are we trying to use the
> combination of overlayfs and fscr
Am Mittwoch, 13. März 2019, 16:16:33 CET schrieb Theodore Ts'o:
> So before we talk about how to make things work from a technical
> perspective, we should consider what the use case happens to be, and
> what are the security requirements. *Why* are we trying to use the
> combination of overlayfs
On Wed, Mar 13, 2019 at 04:26:54PM +0200, Amir Goldstein wrote:
> On Wed, Mar 13, 2019 at 3:34 PM Richard Weinberger wrote:
> >
> > Am Mittwoch, 13. März 2019, 14:24:47 CET schrieb Miklos Szeredi:
> > > > The use case is that you can delete these files if the DAC/MAC
> > > > permissions allow it.
On Wed, Mar 13, 2019 at 04:26:54PM +0200, Amir Goldstein wrote:
> AFAIK, this feature was born to tailor Android's file based encryption.
> https://source.android.com/security/encryption#file-based
> It is meant to protect data at rest and what happens when user enters
> the screen lock password II
Hi Miklos,
On Wed, Mar 13, 2019 at 02:24:47PM +0100, Miklos Szeredi wrote:
> On Wed, Mar 13, 2019 at 2:00 PM Richard Weinberger wrote:
> >
> > Am Mittwoch, 13. März 2019, 13:58:11 CET schrieb Miklos Szeredi:
> > > On Wed, Mar 13, 2019 at 1:47 PM Richard Weinberger wrote:
> > > >
> > > > Am Mittw
On Wed, Mar 13, 2019 at 3:34 PM Richard Weinberger wrote:
>
> Am Mittwoch, 13. März 2019, 14:24:47 CET schrieb Miklos Szeredi:
> > > The use case is that you can delete these files if the DAC/MAC
> > > permissions allow it.
> > > Just like on NTFS. If a user encrypts files, the admin cannot read
Am Mittwoch, 13. März 2019, 14:24:47 CET schrieb Miklos Szeredi:
> > The use case is that you can delete these files if the DAC/MAC permissions
> > allow it.
> > Just like on NTFS. If a user encrypts files, the admin cannot read them but
> > can
> > remove them if the user is gone or loses the ke
On Wed, Mar 13, 2019 at 2:00 PM Richard Weinberger wrote:
>
> Am Mittwoch, 13. März 2019, 13:58:11 CET schrieb Miklos Szeredi:
> > On Wed, Mar 13, 2019 at 1:47 PM Richard Weinberger wrote:
> > >
> > > Am Mittwoch, 13. März 2019, 13:36:02 CET schrieb Miklos Szeredi:
> > > > I don't get it. Does f
Am Mittwoch, 13. März 2019, 13:58:11 CET schrieb Miklos Szeredi:
> On Wed, Mar 13, 2019 at 1:47 PM Richard Weinberger wrote:
> >
> > Am Mittwoch, 13. März 2019, 13:36:02 CET schrieb Miklos Szeredi:
> > > I don't get it. Does fscrypt try to check permissions via
> > > ->d_revalidate? Why is it no
On Wed, Mar 13, 2019 at 1:47 PM Richard Weinberger wrote:
>
> Am Mittwoch, 13. März 2019, 13:36:02 CET schrieb Miklos Szeredi:
> > I don't get it. Does fscrypt try to check permissions via
> > ->d_revalidate? Why is it not doing that via ->permission()?
>
> Please let me explain. Suppose we have
Am Mittwoch, 13. März 2019, 13:36:02 CET schrieb Miklos Szeredi:
> I don't get it. Does fscrypt try to check permissions via
> ->d_revalidate? Why is it not doing that via ->permission()?
Please let me explain. Suppose we have a fscrypto directory /mnt and
I *don't* have the key.
When reading
On Wed, Mar 13, 2019 at 1:31 PM Richard Weinberger wrote:
>
> Hi!
>
> overlayfs and fscrypt are not friends.
> Currently it is not possible to use a fscrypt encrypted directory as upper
> directory with overlayfs.
> The reason for that is, fscrypt implements ->d_revalidate().
>
> From fscrypt's po
36 matches
Mail list logo
