[apparmor] apparmor with large profile set

[Alexandre Pujol]

Hi,

On 18/07/2023 03:02, Seth Arnold wrote:
 > What exactly do you mean with "the doc"? The wiki has a lot of syntax
 > and semantics around future expansion plans and I've seen dozens, if not
 > hundreds, of questions from people who found it and tried to use it on
 > live systems, without success.

I was doing reference in the wiki in general and in the policy reference 
in particular as I am part of the people that tried stuff from it 
without success ;)

I could work myself on improving it, however I am not myself aware of 
what is already here or planned. I may have a look at the man page next 
time, that could save me some time.


On 18/07/2023 05:01, John Johansen wrote:
> 
> Jul 10 11:51:22 aa-archlinux-gnome gnome-shell[1754]: AT-SPI: Error 
> retrieving accessibility bus address: 
> org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible 
> causes include: the remote application did not send a reply, the message 
> bus security policy blocked the reply, the reply timeout expired, or the 
> network connection was broken.
> 
> 
> And org.freedesktop.systemd1 seems to be an issue, while the 
> non-apparmor log has some failures it successfully starts the service as 
> part of the session
> Jul 10 11:52:48 aa-archlinux-gnome dbus-daemon[439]: [session uid=120 
> pid=439] Successfully activated service 'org.freedesktop.systemd1'
> Jul 10
> 
> the apparmor log does not succeed in launching the service, throwing up 
> about 10 more errors around it than the non-apparmor log
> 
> nothing definitive but some avenues to research
> 

The weird thing is that this is on Archlinux, there is no dbus mediation 
in place anyway.


 > this can't change, it would break policy, even if we update all policy
 > in the system there is policy being shipping by too many other projects.
 > For better or worse the apparmor rules are based on shell globbing not
 > RE or eRE. There is a potential for exposing a full RE with special
 > syntax. Something like
 >
 >    ^/foo[1-7]*$
 >

I get that breaking 20 years of profile is not a good thing...
Adding a new syntax seems a good idea, I wonder how this could be used 
in variables.

 >> **no-new-privs**
 >>
 > yeah, another one we need to get upstream. The question has been exactly
 > what we can get upstream before we make it available more broadly. This
 > should be coming within the next couple kernel releases.

Out of curiosity, do you have a kernel somewhere that I could use to 
test it?

 >> **Snap**
 >>
 > Any where it exists today with get replaced with a variable with
 > a name that has the semantic intent. It may get set to unconfined, but
 > it will at least be easier to make changes.

That a nice idea, do you know when this change will be done?


Regards,
Alex