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!
signature.asc
Description: OpenPGP digital signature
-- AppArmor mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
