[apparmor] 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.