[Apparmor-general] problem with profiling sshd under OpenSuSE 10.2

[Seth Arnold]

On Fri, Feb 09, 2007 at 12:14:04AM +0100, ps wrote:
> Hello I spent a few hours for tunning sshd profile which is shipped with
> AA in OpenSuSE10.2. I would like to use profile in which I can indicate
> which programs can be run under user session. For example some user log
> in(via ssh) his account and I can indicate for him what program he can
> use, others are denied. Can I do this with AA?

Yes, you can; we have a more detailed description of one way to
accomplish this task posted here:
http://lists.opensuse.org/opensuse-security/2006-12/msg00004.html
I'll quickly summarize..

> I think I should create some profile for /bin/bash because programs
> which users can use are run under /bin/bash. If I have profile for
> /bin/bash I will be able to confine /bin/bash to some set of programs.
> In original profile shipped with OpenSuSE10.2 /bin/bash has Ux
> permissions. It meens no control for bash and programs which are run
> under it.

Correct. Once upon a time we actually shipped this sshd profile turned
on by default. Since we didn't want to break every user's system, we had
to unconfine the shells. Needless to say, this profile provided nearly
no security value, so we turned it off. However, aside from the shells,
it does provide some useful information to people creating their own
sshd profiles in conjunction with our pam_apparmor module.

(Actually, -did- this sshd profile provide you with anything
interesting? I think enough may have changed since we last updated this
profile for it to be useless. I've considered removing it entirely.)

> There is also security note on Novell website abount AA and Ux mode:
> WARNING: Using Unconstrained Execute Mode (Ux)
> 
> "Use Ux only in very special cases. It enables the designated child
> processes to be run without any AppArmor protection. Use this mode only
> if the child absolutely must be run unconfined. Use at your own risk."

Remember this :) The presence of 'Ux' in a profile means the whole
profile is worthless against an attacker -- it does provide value
against accidents, however.

> Do you have any idea how to create this kind of profile. I think it will
> be very useful for everyone how provides shell accounts for users.

The short version:

Preparation:
- start a new unconfined root shell somewhere -- do NOT close this until
  you're done. :)
- install pam_apparmor (from the buildservice for the time being)
  - read the /usr/share/doc/packages/pam_apparmor/README
  - decide if you want per-user or per-group "hats"
  - configure pam as described
- remove all ux and Ux rules from the sshd profile
- make a hardlink from /bin/bash to /bin/confined_bash (pick any name)
- change user shells in /etc/passwd to /bin/confined_bash
  - you can make per-user shells or per-group shells or per-role shells
  - however many you make and what you call them will depend on your
    pam_apparmor configuration as mentioned above

Getting down to work:
- genprof sshd
- rcsshd restart
- login and do whatever you want your users to be able to do
- logout
- return to the genprof sshd terminal and start answering questions
  - Make sure sshd has Px or px access inside the user or group hats to
    the confined shells allowed for that specific user or group
- quit genprof and test it out

Cleanup:
- It never hurts to reboot a system after making changes like this to
  make sure that it will come up cleanly if you lose power or have to
  do unscheduled maintenance. Having non-ssh access to the system is
  a plus. :)
- Make sure users cannot modify /etc/passwd. Do not grant access to e.g.
  chsh. Do not grant write permission to /etc/passwd. Do not grant write
  permission to anything in the bootup process, kernels, modules,
  libraries, system programs, etc..
- Periodically run logprof to see if your users need access to anything
  you may have overlooked. Decide to add/deny each as you wish. Don't
  allow chsh. Don't allow crontab unless you also profile cron.

I hope this helps; don't hesitate to ask if you have questions.

Thanks
-------------- 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/20070209/0327176b/attachment.pgp