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

[ps]

Seth Arnold wrote:
> On Mon, Feb 12, 2007 at 03:22:02PM +0100, ps wrote:
>>> (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.
> 
> Ok, this isn't exactly a "yes keep it" but neither is it a "throw it
> away". ;) If anyone has the time and inclination to profile sshd with
> pam_apparmor from scratch, I'd love to have the result. :) Thanks
> 
>> 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)
> 
> Thanks for the translation :)
> 
>> 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.
> 
> 
> There are a few kinds of ptrace access deep inside the kernel. One kind
> just checks for the capability PTRACE, and the other kind asks the LSM
> if the one process is allowed to trace the other process. We currently
> allow the cap_sys_ptrace capability to be set in the profile, but it
> -might- be completely useless, since we always deny the more specific
> ptrace LSM call for a confined process.
> 
> (A confined process that can easily manipulate another process via
> ptrace is not all -that- confined. :)
> 
> We have considered relaxing the constraints on ptrace, but have no found
> the time to do so yet :(
> 
> We may need to come up with something sooner rather than later, as
> reading some entries from /proc/pid/* now requires ptrace capability.
> 
> Part of a solution may involve introducing a light-weight capability for
> read-only process introspection. Maybe just different security hooks.
> Who knows. :)
> 
> Anyway, anything that needs to read through any of the /proc/pid/
> entries that now requires CAP_SYS_PTRACE won't work with AppArmor. :(
> 
> Thanks
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Apparmor-general mailing list
> Apparmor-general at forge.novell.com
> http://forge.novell.com/mailman/listinfo/apparmor-general
Hello Seth

Thanks you for your answers and explanation.
Currently I'm going to prepare some lab exercise for my students.

Best regards

Peter