[apparmor] profile restriction

[Arnaud VALLAT]

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. :)
> -----Original Message-----
> From: Arnaud VALLAT <rno.rno at gmail.com>
> Sender: apparmor-bounces at lists.ubuntu.com
> Date: Thu, 20 Jan 2011 10:13:12
> To: <apparmor at lists.ubuntu.com>
> Subject: [apparmor] profile restriction
>
> Hello,
>
> I have an apparmor profile for an executable and I want it to be
> applied only on a specific user group and for all other groups I don't
> want any profile.
>
> I know I can have a profile hat but as I understand it it's within an
> apparmor profile and not above.
>
> Thanks in advance for your help.
>
> Rno
> --
>
>   "Given enough eyeballs, all bugs are shallow"
>     Eric Steven Raymond
>
> --
> AppArmor mailing list
> AppArmor at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
>



-- 

  "Given enough eyeballs, all bugs are shallow"
    Eric Steven Raymond