---> Very strange all this did not show up on my previous query to aptitude. <---
A.
Yeh, I noticed that too, aptitude 'why' seems to only show the first one it finds.
This one is more useful;
apt-cache --installed rdepends dbus
and since a boat load of stuff depends on that list,
aptitude purge libapparmor1 (n) (don't press enter)
suggests about 100 others to remove.
Altoid wrote:..
But then you upgrade the kernel and there it is again.
What I always do is purge apparmor after the upgrade..
A.What about holding the package; sudo apt-mark hold apparmor
or even pinning it ?Would the upgrade still go through ?
Hmm ...
No idea.
Have not tried it but I don't see (?) why it shouldn't.
Yes, I guess I could pin it.
ie: the same way I do with pulseaudio and see what happens on the next upgrade.
Bear in mind that there are other apparmor related libraries which are/may be needed by other packages.
eg: libapparmor1
~$ aptitude why libapparmor1
i stress-ng Depends libapparmor1 (>= 2.10)
~$
Edit:
It seems that there's more than stress-ng involved with libapparmor1.
~$ aptitude why libapparmor1
i slim Depends dbus
i A dbus Depends libapparmor1 (>= 2.8.94)
~$
---> Very strange all this did not show up on my previous query to aptitude. <---
I have not used stress-ng in years, so I might as well get rid of it. and solve the issue.
We'll see how the pinning goes.
Best,
A.
]]>..
But then you upgrade the kernel and there it is again.
..What I always do is purge apparmor after the upgrade..
A.
What about holding the package; sudo apt-mark hold apparmor
or even pinning it ?
Would the upgrade still go through ?
]]>So if i use security=none it should only be for SELinux, Smack, Tomoyo, and AppArmor ?
I think they are all kernel "security" modules. That way you can leave out the apparmor=on/off command from the boot line.
I don't know if there are any others.
]]>Doesn't seatd work in chimeara? I can get a Wayland session under Alpine with just that running. EDIT: with sway anyway.
]]>stuga% cat /sys/kernel/security/lsm ; echo
lockdown,capability,yama
i.e., "yama" belongs to the unavoidable default collection of Linux Security Modules
https://kernsec.org/wiki/index.php/Projects
Evenson wrote:
Is it really needed to have boot command security=none ?
... was not aware of this extra step.the security module could be apparmor, selinux, ...
ref. https://www.kernel.org/doc/html/latest/admin-guide/LSM/index.html
"Examples include SELinux, Smack, Tomoyo, and AppArmor."
so, security= , requires none.
Thanks, i read up on this today from the link you posted. Ive no need for any of these except yama via sysctl.
kernel.yama.ptrace_scope=2
So if i use security=none it should only be for SELinux, Smack, Tomoyo, and AppArmor ?
Evenson wrote:
Is it really needed to have boot command security=none ?
... was not aware of this extra step.
the security module could be apparmor, selinux, ...
ref. https://www.kernel.org/doc/html/latest/admin-guide/LSM/index.html
"Examples include SELinux, Smack, Tomoyo, and AppArmor."
so, security= , requires none.
]]>Is it really needed to have boot command security=none ?
... was not aware of this extra step.
You would be if you had taken the time to read the whole thread. 8^D
Check if you have some other stuff called tomoyo, another gift from the Debian devs.
You have to add security=none to the kernel command line to avoid that one.
Best,
A.
]]>In any case, I'd agree that apt-get purge apparmor is best here, and that it also seems to need a security=none setting (or similar) on the boot command line to make the kernel bypass apparmor kernel code.
Is it really needed to have boot command security=none ?
Ive purged apparmor, was not aware of this extra step.