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

[Seth Arnold]

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
-------------- 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/20070212/c972d86e/attachment.pgp