[Apparmor-general] Overly tight subdomain profile broke my SSH key

[John Johansen]

On Mon, Mar 26, 2007 at 05:24:33PM +1000, Michael James wrote:
> On Monday 26 March 2007 1:21 pm, John Johansen wrote:
> > There are 2 variables that could be used here
> > defined in /etc/apparmor.d/tunnables/home
> > @{HOMEDIRS} is a list of directories where users home dirs are and
> > @{HOME} is a list of user directories (currently defined using HOMEDIRS)
> >
> > so the rule would look like
> > @{HOMEDIRS}/*/.ssh/authorized_keys{,2}          r,
> 
> We need to minimise unexpected interdependencies!
> 
true but sometime abstractions are worth adding some iterdependancies.
I actually don't expect HOMEDIRS will be used here.  I expect
it should be HOME.  This would allow the admin to explicitly list which
homes are allowed or provide a pattern.  With the variables admins
hopefully only have to tweak one or two variables instead of multiple
profiles.

And if an admin desires to customize a profile beyond what is provided, it
should be easy to search for the few defined variables instead of trying
to come up with all the possible patterns that could be used to match
say /home/<user>/.ssh

> For good reasons I have always had an extra level in the home dir path.
> Now subdomain can't pick a home directory and keys stop working.
> 
I may be miss understanding you here so correct me if I am wrong but the
current problem is that the profiles we currently ship don't match
your home directory layout (and you are not the only one).  subdomain
currently picks a home directory of /home/*/ and you must modify
profiles to get them to work with any other layout.

Using a variable allows for the admin to easily tweak profiles to make
them work.  The variables could vary well be defined to something wide
like /home/*/ and /home/*/*/.

> The variable  @{HOMEDIRS} still needs to be loaded,
>  leaving the sysadmin liable to some unexpected failures.
> 
yes, if the include that defines the variable is missing it will result
in failures (it should be at profile load/authoring time).  But that is
the case now with any of the includes that contain rules a profile needs.
A profile doesn't need to use variables or includes but having a few
good abstractions can sure make profiles easier to author and understand.

> What @{HOMEDIRS} is trying to say is "a home directory for a valid user".
> Until apparmor can cope with that, how about allowing both
> 	/home/*/.ssh/authorized_keys{,2}	r,
> 	/home/*/*/.ssh/authorized_keys{,2}	r,

I could be miss understanding you here so again correct me if I a wrong, but
apparmor variables do support this.  As I said before they are sorely
under documented, and I will add under utilized, but we are working to
improve their support.

The apparmor variable syntax is a list variable.  Which will expand to
multiple rules.  So doing the following would get what you suggest

@{HOME} = /home/*/ /home/*/*

@{HOME}/.ssh/authorized_keys{,2}	r,

this expands to
/home/*/.ssh/authorized_keys{,2}	r,
/home/*/*/.ssh/authorized_keys{,2}	r,

Another admin may to want his home dir in /home at all (I actually know
of a couple a cases), and then only the variable needs to be tweaked.

Another admin may want to be more restrictive and the @{HOME} variable
could contain the exact list of users
@{HOME} = /home/jjohansen/ /home/foo/ /home/bar/

thanks again
jjohansen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://forge.novell.com/pipermail/apparmor-general/attachments/20070326/5cf6feaa/attachment.pgp