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

[ps]

Seth Arnold wrote:
> 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.)
> 
Hello Seth
Well, generally no. I use default profile for learn myself about AA
profiles and change hat concept.
>> 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
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Apparmor-general mailing list
> Apparmor-general at forge.novell.com
> http://forge.novell.com/mailman/listinfo/apparmor-general

Thanks for great help:)
I have just started profiling my ssh serwer in OpenSuSE10.2.
Everything seems ok but there is one anoying error.
When I try to log in I see some log trail in audit.log like this:

type=APPARMOR msg=audit(1171288571.970:5574): REJECTING access to
syscall 'ptrace' (ls(7542) profile /usr/sbin/sshd active piter)


and in user shell:

piter at pacer:~> ssh piter at localhost
Password:
Last login: Mon Feb 12 14:55:31 2007 from localhost
Have a lot of fun...
Environment:
  LANG=pl_PL.UTF-8
  USER=piter
  LOGNAME=piter
  HOME=/home/piter
  PATH=/usr/bin:/bin:/usr/sbin:/sbin
  MAIL=/var/mail/piter
  SHELL=/bin/confined_bash
  SSH_CLIENT=127.0.0.1 45072 22
  SSH_CONNECTION=127.0.0.1 45072 127.0.0.1 22
  SSH_TTY=/dev/pts/8
  TERM=xterm
/bin/ls: nie moz.na przeczytac' dowia;zania symbolicznego /proc/7540/exe:
Brak doste;pu (ang translation: can't read symbolink link /proc/7540/exe:
Access denied)
piter at pacer:~>

I add to my sshd profile something like this:

capability sys_ptrace and

/proc/* r,
/proc/[0-9]*/exe lixr


but it don't help. What's wrong?
Once more thanks for help.

Peter