[apparmor] AppArmor and Samba

[John Johansen]

On 08/17/2011 01:39 PM, Christian Boltz wrote:
> Hello,
> 
> on Mittwoch, 17. August 2011, Lars Müller wrote:
>> On Wed, Aug 17, 2011 at 08:21:31AM -0700, Roger Luedecke wrote:
>>> On Wednesday, August 17, 2011 04:34:46 AM Marcus Meissner wrote:
> 
>>>> We enabled it for nmbd and smbd in 11.4, which due to very
>>>> flexible nature of smb paths that can be served made it reject
>>>> valid user scenarios. It is kind of hard to confine a service
>>>> which offers read/write access to configurable paths.
>>>
>>> Hmm, sounds like a problematic addition. Maybe the restrictions
>>> should be lifted then.
>>
>> Sounds more like the YaST Samba module needs an enhancement if a new
>> share gets added.  In this case we have to add a fitting AppArmor
>> configuration for this new path too if AppArmor is in use.
> 
> The YaST Samba module is the wrong place IMHO.
> The better place is the Samba initscript (and its systemd equivalent) so 
> that it is also working for people who manually edit smb.conf.
> 
> Copy&paste from my mail from yesterday (shortly before midnight) 
> somewhere else in this thread:
> 
> ---------------------------------------------------------------------
> 
> The main problem is that AppArmor needs to be aware of the location of 
> your shares. The perfect solution would be that Samba or its initscript 
> add the location of all shares (with lrwk permissions) to an AppArmor 
> profile sniplet at startup.
> 
> See also https://bugzilla.novell.com/show_bug.cgi?id=688040 - most 
> interesting comments:
> 
> | Comment 2 - Christian Boltz    2011-04-18 22:11:35 CEST  
> | Agreed. It would still be worth some bonus points if the samba 
> | initscript would auto-generate a profile sniplet with the path of all 
> | shares ;-)
> 
> | Comment 3 - Lars Mueller    2011-04-20 18:30:08 CEST  
> | Free coffee and cake if we see a submit request implementing the 
> | suggestion from comment #2 in a way that it works generic with the 
> | current sysvinit approach and with systemd too.
> 
> Lars didn't write "for the submitter only" - maybe there's someone who 
> wants to make him sponsoring coffee and cake for the conference? *eg*
> 
Another potential solution coming down the pipes are kernel vars and
mount rules.  Basically there could be a solution that doesn't have
to directly update policy but only a single kernel var (easier to auto-gen),
this could be done dynamically without having to reload all of policy.

There are of course lots of details I have left out, and some more
code to handle updating for shares would need to be created but at least
for shares and dynamic filesystems I think there is a better solution
coming than updating packages to do it.


> ---------------------------------------------------------------------
> 
> The bugreport already contains some technical hints - we just need 
> someone who implements it. (If needed, I can help on the AppArmor part.)
> 
> 
> Regards,
> 
> Christian Boltz