On 7/18/23 03:12, Alexandre Pujol wrote:
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.

being ArchLinux, you could very well have dbus mediation in play ;) but it
doesn't have to be dbus mediation causing the problem. It could be that
some unix socket mediation is blocking access to dbus, etc.


 > 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.

Well, there are a couple of ways, some more problematic than others

the variable could be treated as a straight textual substitution, this
would however mean what it represents would change depending on which
rule it is being used in. Which to me makes it worthless.

Variables expansion could detect which form of expression they are being
expanded in and not allow patterns in the variable when expanding in
an RE. Not ideal but avoids the madness that is the text substitution

Variables could be setup to know the type of expression they contain
and there could be a way to switch between expression forms. Which
would allow mixing them. Its not something you would want to happen
often in a regular rule but it would allow the mixing that would be
needed if we exposed an alternate RE syntax.

Or you force all policy compiled together be in the same syntax. This
is cleaner in some ways but would effectively mean managing two sets
of variables, two policy locations, ...


 >> **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?


I have had a few, I need to go through and fix a few things, rebase and
get them working again, now that we have extended permissions landed and
don't have to use hacks to smuggle something into the policy. So not yet
but soon

 >> **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?

I was hoping in a couple weeks, but my backlog just seems to keep getting
longer.


Reply via email to