[apparmor] [patch] Update the sshd profile
Simon Deziel
simon.deziel at gmail.com
Fri Jan 8 01:33:38 UTC 2016
Hi,
On 2016-01-06 12:12 PM, Christian Boltz wrote:
> Am Mittwoch, 6. Januar 2016 schrieb Simon Deziel:
>> On 2016-01-02 09:38 AM, Christian Boltz wrote:
>>> the sshd profile was bitrotting for a while and denies several
>>> permissions that are needed for a successful ssh login (see the
>>> patch for details).
>>>
>>> While on it, I added owner restrictions to the @{PROC}/@{pid} rules,
>>> except @{PROC}/@{pids}/fd/ which is used with the pid of the
>>> just-logged in user's shell (therefore changed to @{pids}).
>>>
>>> The patch makes the sshd profile working on Debian (which initially
>>> caused this patch via a bugreport) and openSUSE.
>>>
>>>
>>> An interesting question is
>>> + @{PROC}/cmdline r,
>>> + @{PROC}/1/environ r,
>>>
>>> These permissions don't seem to be really needed (sshd and ssh
>>> logins
>>> still work if denying it), and it's questionable why sshd needs to
>>> read them. Therefore the question is if we want to use 'deny' for
>>> those two.
>>>
>>>
>>> References: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809649
>>>
>>>
>>>
>>> I propose this patch for trunk, 2.10 and 2.9.
>>>
>>> In your review, please also state if you want allow or deny rules
>>> for
>>> reading /proc/cmdline and /proc/1/environ.
>>
>> I don't know about /proc/cmdline but in the past, I've seen PID 1
>> being examined to figure the default rlimits for the sandbox. Maybe
>> this is for something similar?
>
> Good question, but unfortunately I don't have an answer :-(
>
>>> [ update-sshd-profile.diff ]
>>>
>>> === modified file 'profiles/apparmor/profiles/extras/usr.sbin.sshd'
> ...
>> Those changes are good on their own
>
> OK, so I'll hope someone sends an Ack for the patch ;-)
>
>> but the resulting profile leaves
>> to desire: no DBUS support, no support to change an expired password,
>> etc.
>
> Those are things I've never seen happen - but that doesn't mean much.
> I'm using SSH quite often, but probably only "the usual stuff". Also,
> the openSUSE kernel doesn't have AppArmor DBUS support, so I'll never
> get denials for that.
>
> BTW: DBUS support in SSH? I didn't even imagine it could be there ;-)
> Any hints what it does?
That's the first thing I tripped on when enabling the profile in 14.04.
Upon connection, it sends a Hello to org.freedesktop.DBus then create
the session via org.freedesktop.login1.Manager. The ReleaseSession is
when you log out.
>> I've put significant effort and testing on a forked profile [1] for
>> 14.04. I'm currently testing OpenSSH 7.1 on 16.04 and will publish the
>> results on GitHub as well. I would be glad to help merge those back
>> if there is interest.
>
> Yes, there is always interest in getting profiles updated - and ideally
> we can make profiles good enough to be enabled by default.
>
> So yes, please send your changes (as patches or as bzr merge requests).
> Ideally you should do that directly after updating the profile, so that
> we can still find out why something that looks interesting[tm] is needed.
OK, I'll propose a bzr merge soon.
> Speaking about your updated sshd profile - it seems you changed several
> rules to execute a shell from Ux to PUx. In general, shells won't have
> their own profile, so - what's the reason for this change?
Indeed, in general they don't have a profile but why not allow one to
add one? That's why I always use PUx instead.
Did I misunderstood how Ux work? Say I have a profile defined for
/bin/bash would Ux allow a transition to it?
> BTW: Your sshd profile just caused a small patch - see the separate mail
> I just sent ;-)
Thanks!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20160107/d7be0fc0/attachment.pgp>
More information about the AppArmor
mailing list