Mailinglist Archive: opensuse-factory (394 mails)

< Previous Next >
Re: AppArmor changes (was: [opensuse-factory] New Tumbleweed snapshot 20180101 released!)
Hello,

thanks for the info about docker - that explains why the docker profile
was loaded :-)

Also, upstream was fast in providing a patch that make cache write
failures only a warning. I just submitted SR 561675 to get this patch
into Tumbleweed.

To answer your aside:

Am Donnerstag, 4. Januar 2018, 00:23:31 CET schrieb Aleksa Sarai:
On 2018-01-04, Aleksa Sarai <asarai@xxxxxxx> wrote:
As a complete aside -- there is also currently an AppArmor design
flaw, where unloading a profile (ie. restarting the "AppArmor
service") will make all previously confined processes unconfined --
with no way for an administrator to re-confine them (other than
attaching to each process with GDB and executing aa_changehat from
the context of the process).

Yes, that's why I changed apparmor.service to
ExecStop=/bin/true
in 2.12 to prevent that from accidently happening. This results in
"restart" behaving like "reload" now.

Needless to say that this is not my favorite solution. A better solution
would be ExecRestart= in apparmor.service, but the systemd developers
refused to implement ExecRestart= despite several people asking for it.
As I already wrote two mails ago, [insert systemd rant here] ;-)
(If you are interested in more details, one of the bugreports mentioned
two mails ago includes the link to the discussion on systemd-devel.)

Is there a reason that restarting the "apparmor service" does
anything at all? We really should not be removing profiles
automatically given this fairly glaring security problem.

My straw-man pitch would be that "systemctl restart apparmor" should

For restart vs. reload, see above.

only *replace* profiles that are stored in /etc/apparmor.d. If a
profile is not present in /etc/apparmor.d (and *especially* if it's
currently confining a process) then the "apparmor service" should not
touch it. This could be a good stop-gap until profile removal
semantics are fixed in AppArmor.

This was a different problem, and should be fixed since AppArmor 2.11.1
and 2.10.3 - starting with those versions, "unknown" profiles don't get
unloaded on reload. (Use aa-remove-unknown to unload profiles that don't
exist in /etc/apparmor.d/)

If you still can trigger this issue with current AppArmor versions,
please tell me or open a bugreport.


Regards,

Christian Boltz
--
Er wollte den Wert verändern. 0/1 sind zwei verschiedene Werte. Er
kann also egal welchen Wert er vorher hatte den Wert ändern. ;-)
[dfroehling in suse-programming]



--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >