[apparmor] profile restriction

[John Johansen]

On 01/20/2011 03:21 AM, Seth Arnold wrote:
> Aha! The guest session ought to make this easier. :)
> 
> In the gdm-guest-session profile, you should be able to add a line like this:
> 
>   /path/to/untrusted/program Px -> untrusted_program,
> 
> Then add a new file to /etc/apparmor.d/untrusted_program that contains something like this:
> 
> profile untrusted_program {
> 
>   /path/to/untrusted/program rmix,
>   owner @{HOME}/whatever r,
>   ...
> }
> 
> This way, only the execution from gdm-guest-session will get the profile.
> 
> You could also use 'cx' and just place the child profile in gdm-guest-session, it depends which way you think is cleaner. (I think the cx approach makes sense when the program is a helper or module of the main profile, and px to a named profile makes sense when the two have only a slight relationship.)
> 
> But both get the job done very nearly identically.
> 
> Incidentally, in gdm-guest-session I was stunned to see /dev/** rw, (why not use <abstractions/audio>? Granting write privs to the hard drives seems excessive just to grant sound card access...), /media/** rmwlixk, (yikes, but might still be best..), and /var/run rmwkix, (when would 'm' or 'ix' ever be necessary? Why not list which specific sockets may be written?). You might want to restrict guest a bit further.
> 
> -----Original Message-----
> From: Arnaud VALLAT <rno.rno at gmail.com>
> Date: Thu, 20 Jan 2011 12:00:43 
> To: <seth.arnold at gmail.com>
> Cc: <apparmor at lists.ubuntu.com>
> Subject: Re: [apparmor] profile restriction
> 
> Hello,
> 
> thank you for your quick answer!
> 
> Actually, I'm using the guest account of Ubuntu (Maverick). I still
> have local accounts but I need the guest one. Within the guest account
> I need to apply security rules on an executable but not on local
> accounts. I have already modify the gdm-guest-session to add a px rule
> for my executable, and then I have written a profile for my
> executable. I have tried to add a sub profile to the gdm-guest-session
> to avoid having a global one but it does not work or I'm doing it the
> wrong way...
> 
> If I use the method you've mentioned, it means I have a profile which
> is already applied to the executable and then hats within it. But I
> don't want a profile to be applied for local accounts, I just want
> this profile to be applied if it's in guest group.
> 
> Regards,
> 
> Rno
> 
> On Thu, Jan 20, 2011 at 11:20 AM, Seth Arnold <seth.arnold at gmail.com> wrote:
>> Hello Arnaud,
>>
>> There is no easy way to accomplish what you want.
>>
>> If it were my problem to solve, I would use pam_apparmor to confine the different groups differently at login. You add lines like
>>
>>    session required pam_apparmor.so
>> or
>>    session optional pam_apparmor.so
>>
>> to your /etc/pam.d/ config files; you can use common-session if you want, but BE VERY SURE about the profiles before you use 'required'. Read the /usr/share/doc/libpam-apparmor/README first.
>>
>> If you configure your sshd to use groups for the hat names, you could configure your sshd profile with 'student', 'faculty', and 'admin' groups, giving each the privileges you want. 'admin' may get /bin/bash Ux, 'faculty' might get /bin/bash px -> faculty_profile, and similar for 'student'. Then configure the faculty_profile to include the privileges you want, or /bin/bash Ux if you trust them :) and your student_profile profile could either have /silly/program rmix, (if you want to keep it simple) or /silly/program Px -> student_silly_program.
>>
>> In your student_profile, you can't just use /silly/program Px, that would force you to define a /silly/program profile which would be used when an unconfined process (admins too :) try to execute it.
>>
>> Confining the login of a class of users you don't trust to run the program unconfined probably makes sense: if they were unconfined, they might be able to copy the program to another location or make a hardlink to the program to give it a new name and bypass the apparmor profile.
>>
>> I hope this helps. If I'm unclear or you want better examples, I'll help more when I have a better keyboard. :)

If you go the px route the name is globally visible so you want to make
sure it doesn't start with a / (as in Seth's example), unless you want
it to be used by other users/groups.  Profiles that begin with a / are
matched against for attachment by unconfined processes.  Seth's example
works, and would allow the profile to be shared if you started confining
another user account.

Going with cx allows you to keep the name localized applying to only
programs run within the gdm-guest-session.  And you can use profiles that
attach by executable name
  eg.

     /silly/program  Cx,
     # profile embedded within the gdm-guest-session
     profile /silly/profile {
       ..
     }

or profiles that require you to specify the profile name in transition
(no leading /)

     /silly/program  Cx -> unattached,
     #profile embedded within the gdm-guest-session
     profile unattached {
       ..
     }