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
