[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