Making AppArmor work with new mount context API

Making AppArmor work with new mount context API

[David Howells]

Hi John,

I've been having a look at making AppArmor work with the new mount API, the
basic infrastructure for which can be found here:

	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=mount-context

but this doesn't work for AppArmor.  Unfortunately, I've come across a tricky
problem that I'm not sure how to solve, but maybe you can help with.

The issue involves how apparmor evaluates a DFA in do_match_mnt().  The DFA is
fed the following things in the order:

 (1) Mountpoint path.

 (2) Device name.

 (3) File system type.

 (4) MS_* flags.

 (5) Non-binary mount data string (ie. mount options).

However, what I want to do is make it so that:

 (1) MNT_* flags are differentiated from SB_* flags (ie. MS_* flags don't get
     past the syscall interface).

 (2) The superblock is set up as a separate step from the mounting step, prior
     to the mounting step and then the mounting step may be repeated multiple
     times for a given context, eg.;

	fd = fsopen("ext4");
	write(fd, "d /dev/sda2");
	write(fd, "o user_xattr");
	write(fd, "o acl");
	write(fd, "o data=ordered");
	write(fd, "x create");
	// We now have a superblock and we can now query fs data
	write(fd, "q block_size");
	read(fd, query_buffer);
	// Mount three times
	fsmount(fd, "/mnt/a", MNT_NODEV | MNT_NOEXEC);
	fsmount(fd, "/mnt/b", 0);
	fsmount(fd, "/mnt/c", 0);
	close(fd);

 (3) We can pick an existing object and then create a bind mount by something
     like:

	fd = fspick("/mnt/a");
	fsmount(fd, "/mnt/d");
	close(fd);

 (4) We can reconfigure (~= remount) a superblock by picking it, setting
     parameters and then executing the reconfigure, eg.:

	fd = fspick("/mnt/a");
	write(fd, "o ro");
	write(fd, "x reconfigure");
	close(fd);

     (Note that I want to use this opportunity to make reconfiguration atomic
      with all the parameter error checking being done first).

 (5) Any particular option value may exceed a page in size and the total set
     of options may exceed a page in size.  We can do this because the options
     are delivered with write() and then parsed immediately.

 (6) Any particular option could be binary rather than text.  write() is given
     the size of the blob, so we don't need to guess.  This feature could be
     used to pass authentication data, say, for a network fs.

So the order in which Apparmor evaluates its DFA is really inconvenient.
Ideally it would be:

 (1) Filesystem type.

 (2) Device name.

 (3) SB_* flags.

 (4) Options, passed one at a time (it doesn't look like it would be a problem
     to save the intermediate DFA state).

save this DFA state, then for each mount attempt, begin with the saved state
and add:

 (5) Mount path.

 (6) MNT_* flags.

I don't suppose the DFA is created such that it doesn't matter what the order
is?  I would really like to avoid having to buffer the entire option set as a
text string just so that Apparmor can parse it for each mount (though this
could be done inside Apparmor code as the fs_context struct gives the active
LSM somewhere to save state).

Thanks,
David

Re: Making AppArmor work with new mount context API

[John Johansen]

On 01/09/2018 08:37 AM, David Howells wrote:
> Hi John,
> 
> I've been having a look at making AppArmor work with the new mount API, the
> basic infrastructure for which can be found here:
> 
> 	https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=mount-context
> 
> but this doesn't work for AppArmor.  Unfortunately, I've come across a tricky
> problem that I'm not sure how to solve, but maybe you can help with.
> 
> The issue involves how apparmor evaluates a DFA in do_match_mnt().  The DFA is
> fed the following things in the order:
> 
>  (1) Mountpoint path.
> 
>  (2) Device name.
> 
>  (3) File system type.
> 
>  (4) MS_* flags.
> 
>  (5) Non-binary mount data string (ie. mount options).
> 

yep

> However, what I want to do is make it so that:
> 
>  (1) MNT_* flags are differentiated from SB_* flags (ie. MS_* flags don't get
>      past the syscall interface).
> 
makes sense

>  (2) The superblock is set up as a separate step from the mounting step, prior
>      to the mounting step and then the mounting step may be repeated multiple
>      times for a given context, eg.;
> 
> 	fd = fsopen("ext4");
> 	write(fd, "d /dev/sda2");
> 	write(fd, "o user_xattr");
> 	write(fd, "o acl");
> 	write(fd, "o data=ordered");
> 	write(fd, "x create");
> 	// We now have a superblock and we can now query fs data
> 	write(fd, "q block_size");
> 	read(fd, query_buffer);
> 	// Mount three times
> 	fsmount(fd, "/mnt/a", MNT_NODEV | MNT_NOEXEC);
> 	fsmount(fd, "/mnt/b", 0);
> 	fsmount(fd, "/mnt/c", 0);
> 	close(fd);
> 
okay

>  (3) We can pick an existing object and then create a bind mount by something
>      like:
> 
> 	fd = fspick("/mnt/a");
> 	fsmount(fd, "/mnt/d");
> 	close(fd);
> 
>  (4) We can reconfigure (~= remount) a superblock by picking it, setting
>      parameters and then executing the reconfigure, eg.:
> 
> 	fd = fspick("/mnt/a");
> 	write(fd, "o ro");
> 	write(fd, "x reconfigure");
> 	close(fd);
> 
>      (Note that I want to use this opportunity to make reconfiguration atomic
>       with all the parameter error checking being done first).
> >  (5) Any particular option value may exceed a page in size and the total set
>      of options may exceed a page in size.  We can do this because the options
>      are delivered with write() and then parsed immediately.
> 
>  (6) Any particular option could be binary rather than text.  write() is given
>      the size of the blob, so we don't need to guess.  This feature could be
>      used to pass authentication data, say, for a network fs.
> 
> So the order in which Apparmor evaluates its DFA is really inconvenient.
> Ideally it would be:
> 
>  (1) Filesystem type.
> 
>  (2) Device name.
> 
>  (3) SB_* flags.
> 
>  (4) Options, passed one at a time (it doesn't look like it would be a problem
>      to save the intermediate DFA state).
> 

right, there are a couple places where we store and restart based off
of a saved state

> save this DFA state, then for each mount attempt, begin with the saved state
> and add:
> 
>  (5) Mount path.
> 
>  (6) MNT_* flags.
> 
> I don't suppose the DFA is created such that it doesn't matter what the order
> is?

it isn't atm, but the ability reorder and change the parameters set is
planned for to provide extended conditional support. So once that
lands a reordering would be possible.

Basically instead of hard coding the match order, policy will get a
vector that will be used to determine the set of conditionals and the
order to match them in.

> I would really like to avoid having to buffer the entire option set as a
> text string just so that Apparmor can parse it for each mount (though this
> could be done inside Apparmor code as the fs_context struct gives the active
> LSM somewhere to save state).
> 

that would be ugly but acceptable as an intermediate solution until I
can land the extended conditionals support.

I am not sure which is the quickest approach to get apparmor out of
the way for the new mount API. I can accelerate the extended
conditional work some by making mount mediation the first to use it,
but my guess is buffering the option set will still be a little
quicker as the extended conditional rework will require both kernel
and policy compiler work.

Re: Making AppArmor work with new mount context API

[David Howells]

John Johansen <john.johansen@canonical.com> wrote:

> I am not sure which is the quickest approach to get apparmor out of
> the way for the new mount API.

For the moment, the attached patch compiles.  It will need folding into the
main patch.  I've pushed my tree out to:

	git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git

on branch init_task.

Currently, it's using the sb_mount LSM hook to check remount, but this will
need to be changed once the user interface is solidified.  THe problem is
getting the target path through to apparmor.

David