To make ubifs compatible with IMA nad EVM security modules:
- we need to notify them about inode changes over inode->i_version
- provide super block uuid to allow fs choice by uuid.
Oleksij Rempel (1):
fs: ubifs: update i_version on inode changes
Steffen Trumtrar (2):
fs: ubifs: parse iversion mount option
fs: ubifs: set s_uuid in super block
fs/ubifs/file.c | 9 +++++++++
fs/ubifs/super.c | 8 +++++++-
2 files changed, 16 insertions(+), 1 deletion(-)
--
2.11.0
From: Steffen Trumtrar <[email protected]>
this option is needed to make UBIFS work with IMA.
Signed-off-by: Steffen Trumtrar <[email protected]>
Signed-off-by: Oleksij Rempel <[email protected]>
---
fs/ubifs/super.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index b73811bd7676..bff1e8d6f7bd 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -931,6 +931,7 @@ enum {
Opt_chk_data_crc,
Opt_no_chk_data_crc,
Opt_override_compr,
+ Opt_i_version,
Opt_err,
};
@@ -942,6 +943,7 @@ static const match_table_t tokens = {
{Opt_chk_data_crc, "chk_data_crc"},
{Opt_no_chk_data_crc, "no_chk_data_crc"},
{Opt_override_compr, "compr=%s"},
+ {Opt_i_version, "i_version"},
{Opt_err, NULL},
};
@@ -986,6 +988,7 @@ static int ubifs_parse_options(struct ubifs_info *c, char *options,
return 0;
while ((p = strsep(&options, ","))) {
+ struct super_block *sb = c->vfs_sb;
int token;
if (!*p)
@@ -1042,10 +1045,12 @@ static int ubifs_parse_options(struct ubifs_info *c, char *options,
c->default_compr = c->mount_opts.compr_type;
break;
}
+ case Opt_i_version:
+ sb->s_flags |= MS_I_VERSION;
+ break;
default:
{
unsigned long flag;
- struct super_block *sb = c->vfs_sb;
flag = parse_standard_option(p);
if (!flag) {
--
2.11.0
increment i_version to notify security/IMA about changes
made in inode.
Signed-off-by: Oleksij Rempel <[email protected]>
---
fs/ubifs/file.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/fs/ubifs/file.c b/fs/ubifs/file.c
index d9ae86f96df7..29213724259b 100644
--- a/fs/ubifs/file.c
+++ b/fs/ubifs/file.c
@@ -1104,6 +1104,8 @@ static void do_attr_changes(struct inode *inode, const struct iattr *attr)
mode &= ~S_ISGID;
inode->i_mode = mode;
}
+ if (IS_I_VERSION(inode))
+ inode_inc_iversion(inode);
}
/**
@@ -1401,6 +1403,9 @@ int ubifs_update_time(struct inode *inode, struct timespec *time,
if (!(inode->i_sb->s_flags & MS_LAZYTIME))
iflags |= I_DIRTY_SYNC;
+ if (IS_I_VERSION(inode))
+ inode_inc_iversion(inode);
+
release = ui->dirty;
__mark_inode_dirty(inode, iflags);
mutex_unlock(&ui->ui_mutex);
@@ -1435,6 +1440,8 @@ static int update_mctime(struct inode *inode)
mutex_lock(&ui->ui_mutex);
inode->i_mtime = inode->i_ctime = ubifs_current_time(inode);
+ if (IS_I_VERSION(inode))
+ inode_inc_iversion(inode);
release = ui->dirty;
mark_inode_dirty_sync(inode);
mutex_unlock(&ui->ui_mutex);
@@ -1580,6 +1587,8 @@ static int ubifs_vm_page_mkwrite(struct vm_fault *vmf)
mutex_lock(&ui->ui_mutex);
inode->i_mtime = inode->i_ctime = ubifs_current_time(inode);
+ if (IS_I_VERSION(inode))
+ inode_inc_iversion(inode);
release = ui->dirty;
mark_inode_dirty_sync(inode);
mutex_unlock(&ui->ui_mutex);
--
2.11.0
From: Steffen Trumtrar <[email protected]>
This is need to provide uuid based integrity functionlity for:
imy_policy (fsuuid option) and evmctl (--uuid option).
Signed-off-by: Steffen Trumtrar <[email protected]>
Signed-off-by: Oleksij Rempel <[email protected]>
---
fs/ubifs/super.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index bff1e8d6f7bd..a584b2f2b11d 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -2077,6 +2077,7 @@ static int ubifs_fill_super(struct super_block *sb, void *data, int silent)
err = -ENOMEM;
goto out_umount;
}
+ memcpy(&sb->s_uuid, &c->uuid, sizeof(c->uuid));
mutex_unlock(&c->umount_mutex);
return 0;
--
2.11.0
On Tue, Apr 11, 2017 at 11:50:54AM +0200, Oleksij Rempel wrote:
> increment i_version to notify security/IMA about changes
> made in inode.
>
> Signed-off-by: Oleksij Rempel <[email protected]>
And how is this stored on disk?
Oleksij,
Am 11.04.2017 um 11:50 schrieb Oleksij Rempel:
> From: Steffen Trumtrar <[email protected]>
>
> This is need to provide uuid based integrity functionlity for:
> imy_policy (fsuuid option) and evmctl (--uuid option).
>
> Signed-off-by: Steffen Trumtrar <[email protected]>
> Signed-off-by: Oleksij Rempel <[email protected]>
> ---
> fs/ubifs/super.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
> index bff1e8d6f7bd..a584b2f2b11d 100644
> --- a/fs/ubifs/super.c
> +++ b/fs/ubifs/super.c
> @@ -2077,6 +2077,7 @@ static int ubifs_fill_super(struct super_block *sb, void *data, int silent)
> err = -ENOMEM;
> goto out_umount;
> }
> + memcpy(&sb->s_uuid, &c->uuid, sizeof(c->uuid));
Makes sense.
Artem, do you remember why UBIFS didn't set s_uuid in first place?
Thanks,
//richard
Am 11.04.2017 um 18:05 schrieb Christoph Hellwig:
> On Tue, Apr 11, 2017 at 11:50:54AM +0200, Oleksij Rempel wrote:
>> increment i_version to notify security/IMA about changes
>> made in inode.
>>
>> Signed-off-by: Oleksij Rempel <[email protected]>
>
> And how is this stored on disk?
>
Hehe, I was about to ask the same question. :-)
Thanks,
//richard
On Tue, Apr 11, 2017 at 10:43:26PM +0200, Richard Weinberger wrote:
> Artem, do you remember why UBIFS didn't set s_uuid in first place?
It's an extremely odd field - only a hand full of file systems set it
(e.g. XFS doesn't, although according to Mimi IMA supports XFS), and
it's never even used outside of the IMA/EVM code.
We really need a feature flag that this field is valid that IMA can
check before adding more support for it.
On Tue, Apr 11, 2017 at 11:13:24PM +0200, Richard Weinberger wrote:
> Am 11.04.2017 um 18:05 schrieb Christoph Hellwig:
> > On Tue, Apr 11, 2017 at 11:50:54AM +0200, Oleksij Rempel wrote:
> >> increment i_version to notify security/IMA about changes
> >> made in inode.
> >>
> >> Signed-off-by: Oleksij Rempel <[email protected]>
> >
> > And how is this stored on disk?
> >
>
> Hehe, I was about to ask the same question. :-)
No. it is not stored to fs.
Heh, the same question i asked my self. On linux-ima-user i found
this post (2009-07-23):
https://sourceforge.net/p/linux-ima/mailman/message/23152923/
---
When an inode entry is removed from dcache, the corresponding iint entry
is removed from the radix tree. Unmounting an fs will cause the inodes,
and by extension iint's, to be freed. When the fs is remounted, any
file accessed will result in allocating a new iint structure with the
i_version set to 0.
---
The code seems to confirm it. So i assumed that IMA don't care if
i_version is stored to disk or not. And i_version is the only way
to notify IMA about inode changes.
Since IMA documentation explecitley set i_version as reqieremt, so this
option was provided as well.
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Wed, Apr 12, 2017 at 08:05:34AM +0200, Oleksij Rempel wrote:
> The code seems to confirm it. So i assumed that IMA don't care if
> i_version is stored to disk or not. And i_version is the only way
> to notify IMA about inode changes.
> Since IMA documentation explecitley set i_version as reqieremt, so this
> option was provided as well.
Maybe IMA doesn't care, but if you set MS_I_VERSION the fs does give
a guarantee. Sp NAK on this patch as-is.
On Tue, Apr 11, 2017 at 11:08:47PM -0700, Christoph Hellwig wrote:
> On Wed, Apr 12, 2017 at 08:05:34AM +0200, Oleksij Rempel wrote:
> > The code seems to confirm it. So i assumed that IMA don't care if
> > i_version is stored to disk or not. And i_version is the only way
> > to notify IMA about inode changes.
> > Since IMA documentation explecitley set i_version as reqieremt, so this
> > option was provided as well.
>
> Maybe IMA doesn't care, but if you set MS_I_VERSION the fs does give
> a guarantee. Sp NAK on this patch as-is.
Ok, it was an expekted NACK :)
Suddenly right now i don't have good ide to solve it. IMA just won't to
know if some runtime changes was made to FS. Currently i can image
fallowing variants:
- rework IMA
- add MS_I_TEMP_VERSION and keep i_version using for it.
- add new variable for external use only. For example: ima_rt_i_version,
or some thing like this.
Other ideas?
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
On Tue, Apr 11, 2017 at 10:48:28PM -0700, Christoph Hellwig wrote:
> On Tue, Apr 11, 2017 at 10:43:26PM +0200, Richard Weinberger wrote:
> > Artem, do you remember why UBIFS didn't set s_uuid in first place?
>
> It's an extremely odd field - only a hand full of file systems set it
> (e.g. XFS doesn't, although according to Mimi IMA supports XFS), and
> it's never even used outside of the IMA/EVM code.
>
> We really need a feature flag that this field is valid that IMA can
> check before adding more support for it.
It seems to be used by mm/cleancache.c
void __cleancache_init_shared_fs()
but this affects only ocfs2.
So, if some flag should be implemented, who should do it? :)
If me, what flag should be created?
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Oleksij,
Am 12.04.2017 um 09:04 schrieb Oleksij Rempel:
> On Tue, Apr 11, 2017 at 11:08:47PM -0700, Christoph Hellwig wrote:
>> On Wed, Apr 12, 2017 at 08:05:34AM +0200, Oleksij Rempel wrote:
>>> The code seems to confirm it. So i assumed that IMA don't care if
>>> i_version is stored to disk or not. And i_version is the only way
>>> to notify IMA about inode changes.
>>> Since IMA documentation explecitley set i_version as reqieremt, so this
>>> option was provided as well.
>>
>> Maybe IMA doesn't care, but if you set MS_I_VERSION the fs does give
>> a guarantee. Sp NAK on this patch as-is.
>
> Ok, it was an expekted NACK :)
> Suddenly right now i don't have good ide to solve it. IMA just won't to
> know if some runtime changes was made to FS. Currently i can image
> fallowing variants:
> - rework IMA
I assumed that you checked that option already. I IMA *really* needs i_version,
we can think of an solution. Adding new filesystem features should be done with
care.
> - add MS_I_TEMP_VERSION and keep i_version using for it.
You mean a non-persistent i_version like fat and exofs use internally?
> - add new variable for external use only. For example: ima_rt_i_version,
> or some thing like this.
hch will hate this for very good reasons. :-)
> Other ideas?
What about making i_version persistent?
We still have some empty fields in UBIFS' inode data structure.
But first we have to be very sure that we need it.
Artem, do you remember why UBIFS does not store i_version?
Thanks,
//richard
Oleksij,
Am 12.04.2017 um 09:15 schrieb Oleksij Rempel:
> On Tue, Apr 11, 2017 at 10:48:28PM -0700, Christoph Hellwig wrote:
>> On Tue, Apr 11, 2017 at 10:43:26PM +0200, Richard Weinberger wrote:
>>> Artem, do you remember why UBIFS didn't set s_uuid in first place?
>>
>> It's an extremely odd field - only a hand full of file systems set it
>> (e.g. XFS doesn't, although according to Mimi IMA supports XFS), and
>> it's never even used outside of the IMA/EVM code.
>>
>> We really need a feature flag that this field is valid that IMA can
>> check before adding more support for it.
>
> It seems to be used by mm/cleancache.c
> void __cleancache_init_shared_fs()
>
> but this affects only ocfs2.
>
> So, if some flag should be implemented, who should do it? :)
I'll not do it for you. ;)
> If me, what flag should be created?
A super block flag that denotes that s_uuid is valid.
Thanks,
//richard
Am 24.04.2017 um 17:47 schrieb Richard Weinberger:
>> So, if some flag should be implemented, who should do it? :)
>
> I'll not do it for you. ;)
Please also see http://marc.info/?l=linux-fsdevel&m=149327990608749&w=2
Thanks,
//richard
On Fri, Apr 28, 2017 at 1:03 AM, Richard Weinberger <[email protected]> wrote:
> Am 24.04.2017 um 17:47 schrieb Richard Weinberger:
>>> So, if some flag should be implemented, who should do it? :)
>>
>> I'll not do it for you. ;)
>
> Please also see http://marc.info/?l=linux-fsdevel&m=149327990608749&w=2
>
Perhaps you meant this:
https://marc.info/?l=linux-fsdevel&m=149328358909709&w=2
There does not seem to be much objections to adding the flag,
so hopefully, we can merge it for v.12 and filesystems and consumers
will pick it up whenever.
Amir.