ID: 203PHID: PHID-TASK-nm4elxvrwnlbxpsolnw6Author: PatrickStatus at Migration Time: invalidPriority at Migration Time: Normal
The purpose of this ticket is to get a grsecurity kernel to work in Whonix (same as Debian for these purposes here) at all. Having #user_documentation on how a user could install it. From there we could build up with automation, perhaps installation by default, verifiable (kernel) builds, etc.
See also:
Also started a discussion with the mempo developers of deterministic grsecurity kernel deb:
GitHub - rickard2/grsecurity-Debian-Installer: Install script for grsecurity for Debian environments looks most promising for now. Much simpler than the mempo-kernel.
Licensing is not sorted out yet:
opened 07:48PM - 28 Feb 15 UTC
closed 10:42PM - 12 Mar 15 UTC
There is currently no license file added or otherwise license stated.
Could you… please state licensing of this code?
Has some other issues:
That script is relatively small and simple. Fixing these issues and/or forking and/or rewriting it depending on how responsive upstream is should be no issue.
TODO:
Foremost, check if that installer is actually working.
2015-03-04 00:04:47 UTC
2015-03-12 23:08:48 UTC
2015-04-15 03:52:53 UTC
2015-04-15 12:54:01 UTC
! In T203#2744, @troubadour wrote:3.2.67-grsec.
Are you sure grsecurity is really active? I’ve run the script with debugging and saw that applying the patch failed. The script succeeded anyhow and installed a kernel that included grsec in its name. But checksec.sh reports, that grsecurity is disabled. Did you make sure grsecurity is enabled using checksec.sh or some other means?
whonixcheck and sdwdate are working with AppArmor disabled.
It’s possibly not because of grsecurity, but because a newer kernel version is being used. So these are possibly AppArmor issues due to a newer kernel version unrelated to grsecurity.
2015-04-16 14:33:18 UTC
Using that script you need to manually enable grsecurity using menuconfig. Otherwise the kernel is named grsecurity but doesn’t have grsecurity enabled. I succeeded building a grsecurity enabled kernel (as per checksec), but it cannot open a graphical KDE desktop yet and there is also a vbox guest additions specific issue (Chapter 12. Troubleshooting ).
2015-04-18 06:21:31 UTC
Yes, the kernel name was appended with -grsec but it was not enabled.
Perhaps a non related issue. Built a kernel after enabling grsec in menuconfig. It did not run because of (apparently) some virtualbox issue (selected Virtualbox guest in the menu). I purged the guest additions. No change with the grsec kernel, but after rebooting with 3.2.0-4-686-pae, kdm does not start automatically. sudo kdm returns nothing.
After reinstalling the guest additions, Workstation boots normally.
2016-01-06 16:26:11 UTC
linux-grsec now in Debian unstable
https://twitter.com/benhutchingsuk/status/684437715941744640
For future out of the box support efforts we would only have to look into maintaining paxctld exception list. A less major task than developing/maintaining grsec-installer. Also changes like default apt-pinning suport would be needed because grsec kernels will stay exclusively in Debian unstable.
2016-01-06 17:40:04 UTC
What is the status of Deprecated/grsecurity - Whonix ? Tested / working in Whonix?
! In T203#7843, @HulaHoop wrote:
https://twitter.com/benhutchingsuk/status/684437715941744640
Nice!
For future out of the box support efforts we would only have to look into maintaining paxctld exception list. A less major task than developing/maintaining grsec-installer.
Would you create/maintain that list?
Also changes like default apt-pinning suport would be needed because grsec kernels will stay exclusively in Debian unstable.
Not a problem as long this is a user documentation only thing. The Apt-Pinning wiki template looks good and unlikely to cause issues.
Let’s implement this a user documentation only thing first. Have some wider testing. [Write a blog post to encourage testing.]
Can you get the Debian linux-grsec package way to use this in Whonix documented/tested?
When that works… Later for more automation / simplification we could reconsider Whonix Dev/APT_Pinning and perhaps create a package that simplifies this.
2016-01-06 19:55:03 UTC
Would you create/maintain that list?
Yes. I am thinking about taking the Arch paxctld list and adjusting executable paths for Debian’s choices. As it is now, the grsec package cannot work with Xorg and so that will need to be sorted out first.
Can you get the Debian linux-grsec package way to use this in Whonix documented/tested?
I will post updates after testing.
Paxrat suggested by Jacob makes exceptions handling easier to manage across package upgrades so they don’t break after the first apt update is downloaded:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090#487
GitHub - subgraph/paxrat: paxrat is a utility to set PaX flags on a set of binaries.
incorporating this package in Whonix is essential for a long term solution.
2016-01-06 20:24:36 UTC
2016-01-06 20:34:12 UTC
2016-01-07 17:12:13 UTC
First I applied the Apt-pinning instructions (Template:Apt-Pinning - Whonix ) then:
sudo su -c "echo -e 'deb http://security.debian.org unstable/updates main contrib non-free\ndeb http://ftp.us.debian.org/debian unstable main contrib non-free' > /etc/apt/sources.list.d/debian-unstable.list"
sudo apt-get install linux-image-4.3.0-1-grsec-686-pae linux-grsec-support-4.3.0-1 linux-grsec-base paxctl
All relevant grsec packages:
linux-grsec-source-4.3 - Linux kernel source for version 4.3 with Debian patches
linux-grsec-support-4.3.0-1 - Support files for Linux 4.3
linux-headers-4.3.0-1-common-grsec - Common header files for Linux 4.3.0-1-grsec
linux-headers-4.3.0-1-grsec-686-pae - Header files for Linux 4.3.0-1-grsec-686-pae
linux-image-4.3.0-1-grsec-686-pae - Linux 4.3 for modern PCs, Grsecurity protection
linux-grsec-base - Linux image base package, grsec featureset
paxctl - new PaX control program for using the PT_PAX_FLAGS marking
List of changes an install triggers. Note gradm2 is installed as a dependency:
The following extra packages will be installed:
firmware-linux-free gradm2 irqbalance libc6-i686 libnuma1 pax-utils
Suggested packages:
linux-patch-grsecurity2 linux-doc-4.3 debian-kernel-handbook
The following packages will be REMOVED:
xserver-xorg-input-all xserver-xorg-input-vmmouse
The following NEW packages will be installed:
firmware-linux-free gradm2 irqbalance libc6-i686 libnuma1 linux-grsec-base
linux-grsec-support-4.3.0-1 linux-image-4.3.0-1-grsec-686-pae pax-utils
paxctl
0 upgraded, 10 newly installed, 2 to remove and 13 not upgraded.
Need to get 35.5 MB of archives.
After this operation, 129 MB of additional disk space will be used.
Paxrat without packaging needs some work to get running like figuring out the correct paths for the binaries and configuration files.
sudo apt-get install golang
Thats how far I got yet and I’ll make a request draft.
2016-01-07 05:21:29 UTC
ETA for subgraphOS alpha: https://twitter.com/attractr/status/684075394509717505
Almost there, SGOS alpha first week of March.
Here it is. There are some blanks that I need help filling and important things like licensing need attention.
Package name : paxratinfo@subgraph.com
URL : https://subgraph.com/
License : ?
The newly packaged grsec kernel makes it easier for anyone to run a more secure kernel. However some major packages like Iceweasel/Tor Browser, JIT interpreters and main components of Gnome and KDE require PaX exceptions because they are not compatible with memory protection features of the enhanced kernel.
Paxrat from the SubgraphOS project is a daemon that maintains and applies rules from an exception list. It has dpkg hooks for taking care of binaries even when updated.
Paxrat is implemented in GoLang and is simple to use.
Also a Grsecurity kernel maintainer are interested to have paxrat packaged. [1]
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090#487
2016-01-07 17:13:29 UTC
2016-01-07 21:27:27 UTC
2016-01-07 22:14:55 UTC
What blanks?
I have no idea what their licensing for this and other packages in Subgraph is.
Who do I put as the upstream author? What email should I use - is the address for general contact enough?
What mail list do I post to?
Sure?
Yes. This is very much what paxd does except its another project and coded in C, Also take a look at the original comment:
paxctl one off runs isn't great for a full solution.
paxrat improves on this as package updates and other things can stomp
on pax related xattributes. paxrat seems very very useful in this
context - we get configuration files as well as dpkg hooks.
2016-01-07 22:26:25 UTC
Until now there is no license file and no license information in the source files either. So for the moment it cannot be considered Libre Software and must be considered proprietary. Please open an issue on paxrat github.
Cannot fill-out upstream author yet either because it’s not declared either. Please open an issue on paxrat github.
Forget the comment. You need to know where to find the code for the hooks. That paxrat repository does not include any dpkg hooks nor claims to ship any of them. These are usually shell scripts, easy to identify. It only writes “Runnable as a hook to a package manager such as dpkg”. Yes sure. Any tools is runnable as hook to dpkg. Doesn’t mean the hook has been written yet. Looks to me those still have to be written.
Where to send [and how (!) - the header does the magic] - is documented here:https://wiki.debian.org/RFP Debian -- Work-Needing and Prospective Packages
2016-01-07 22:43:20 UTC
2016-01-07 23:00:26 UTC
2016-01-08 00:44:57 UTC
2016-01-08 20:46:11 UTC
Upstream has sorted out a lot. Licensing, dpkg hooks and config file comments (pull request by Alexey Derlaft).
Requested release and signed git tags:first release · Issue #6 · subgraph/paxrat · GitHub
Updated the RFP proposal.
To: submit@bugs.debian.org
Package: wnpp
X-Debbugs-CC: desktops@secure-os.org
X-Debbugs-CC: corsac@debian.org
X-Debbugs-CC: jacob@appelbaum.net
X-Debbugs-CC: whonix-devel@whonix.org
* Package name: paxrat
Version : 1
Upstream Author : David McKinney <mckinney@subgraph>
* URL : https://github.com/subgraph/paxrat
* License : GPLv3
Programming Lang: Go
Description : PaX exception daemon for Debian packages.
The newly packaged grsec kernel makes it easier for anyone to run a more secure kernel. However some major packages like Iceweasel/Tor Browser, JIT interpreters and main components of Gnome and KDE require PaX exceptions because they are not compatible with memory protection features of the enhanced kernel.
Paxrat from the SubgraphOS project is a daemon that maintains and applies rules from an exception list. It has dpkg hooks for taking care of binaries even when updated. [2]
Paxrat is implemented in GoLang and is simple to use.
Also a Grsecurity kernel maintainer are interested to have paxrat packaged. [1]
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=605090#487
[2] https://github.com/subgraph/paxrat/blob/master/etc/apt/apt.conf.d/70paxrat
2016-01-08 20:39:01 UTC
2016-01-08 20:47:06 UTC
2016-01-08 20:48:37 UTC
2016-01-10 15:57:31 UTC
Latest post by Yves on status of grsec support and comments on the default settings chosen for the kernel pacage.
It will take some planning for rolling out the package to stable but its available in his repo right now.
Corsac.net - Echoes: linux-grsec in unstable
2016-01-10 16:29:08 UTC
2016-01-11 14:39:57 UTC
2016-01-11 16:08:28 UTC
2016-01-11 17:52:03 UTC
2016-01-11 20:51:19 UTC
Do you think paxrat will require a .d config file folder?
Currently no although I think its planned but its optional thanks to Derlaft’s commit. # style comments are suppoted in the main conf file:
comment in config support · derlaft/paxrat@865273c · GitHub
Would we need a custom paxrat.conf?
Probably. The conf should cover as many packages as possible to be useful to Debian users. Subgraph will be just focusing on a very limited selection of software because they are adding their own curated repo by default AFAIK.
2016-01-11 21:55:41 UTC
Actually,
Do you think paxrat will require a .d config file folder? Would we need a custom paxrat.conf?
was the same question. Just in other words.
If we do need a custom paxrat.conf, then we also need a .d config folder. Otherwise we would have to use config-package-dev displace. Which is not pretty. Should be avoided if upstream is open to .d config folder.
2016-01-11 22:55:42 UTC
2016-01-16 18:54:34 UTC
2016-01-17 14:34:32 UTC
2016-01-17 14:50:57 UTC
My last comment is wrong. David’s description is on point.
I think their main reason for paxrat wouldn’t apply to Whonix as its not a live environment.
Flags can be maintained paxctld’s .conf file
2016-01-17 16:43:24 UTC
All we need is a dpkg hook and a conf file for paxctld (the latter mirrors the Arch Linux one)
/etc/apt/apt.conf.d/70paxctld
DPkg::Post-Invoke { “/sbin/paxctld -c /etc/paxctld.conf”;}
Or it can be run as daemon. Should there be a systemd service file for paxctld?
2016-01-17 16:40:37 UTC
2016-01-17 19:55:58 UTC
To land a grsec kernel ASAP we can use corsac’s Jessie repo.
To obtain a binary package or source package to compile?
To land a grsec kernel ASAP we can use corsac’s Jessie repo.
Can we? Or will this result in the many issues I experience when I compiled a grsecurity kernel inside VirtualBox? Namely, X no longer starting, conflicts with AppArmor that were not there before and other obscure error messages?
At very least I want this kernel capable to run inside Qubes also.
Or it can be run as daemon. Should there be a systemd service file for paxctld?
You tell me. What would the daemon by doing?
In systemd terms, what would be the ExecStart= line?
Does arch linux’s package require a systemd unit? And if not, why would we need one? And if it has one, can re-use it?
2016-01-18 04:15:48 UTC
To obtain a binary package or source package to compile?
Both are possible because he supports Debian Stable dependencies in his repo but my priority is for a binary package installed by default. More details to follow.
Can we? Or will this result in the many issues I experience when I compiled a grsecurity kernel inside VirtualBox? Namely, X no longer starting, conflicts with AppArmor that were not there before and other obscure error messages?
There shouldn’t be any probems with Apparmor. Exceptions for X and other software is what paxctld is for. The settings probably do conflict with Xen and Virtualbox and may need the custom built source package with the appropriate hypervisor compatibility setting enabled:
Security - ArchWiki
I’m not sure so testing on these platforms may be needed.
If that is the situation, then some service can boot the hardened kernel based on virt-what output.
You tell me. What would the daemon by doing?
All examples I saw have paxctld running as a service with no dpkg hooks. Their service files should be reusable.
2016-01-18 05:10:03 UTC
2016-01-18 13:58:09 UTC
Yes. Merge the first two packages.
I am trying to get rid of the third package also. Why are we back to using corsac’s repository? Why not use Debian sid repository and apt pinning instead?
/etc/sysctl.d/grsec.conf → needs a digitdigit- notation. For example 30-grsec.conf or so. Trying to foresee Debian shipping that name which would then conflict with our package.
If we ship an apt pinning file, we should also have it start with a digit, following by an underscore and ending with the .conf extension. For example 30_grsec.conf. I think the days of processing files in .d folders are counted because of Debian internal extensions .dpkg-old and temporary or backup files by editors such as file-name~.
If that is the situation, then some service can boot the hardened kernel based on virt-what output.
So it would only work with KVM and for all others it would use the non-grsec kernel?
If that is the situation, then some service can boot the hardened kernel based on virt-what output.
This is super difficult. virt-what is a userspace tool that requires an already running kernel. At the stage you would need to this detection, there is only grub. And doing such magic at the boot loader stage is very difficult. Another way would be to boot into a temporary kernel/system that runs the detection and then the required kernel using kexec, but this is also very difficult.
Security - ArchWiki indicates, that the binary kernel might not work depending on Debian’s config. Quote:
Xen and virtualbox are not supported (conflicts with CONFIG_PAX_KERNEXEC and CONFIG_PAX_MEMORY_UDEREF)
What’s Debian’s config?
Yves is a Debian developer and his keys are already in the system keyring?
Probably included in the debian-keyring package, which ships a huge aggregated public key file. With the appropriate gpg command that single key could be extracted from there and then copied to /etc/apt/trusted.gpg.d/corsac.gpg. I don’t remember off hand but could certainly figure out this again. However, as said above I hope this route can be avoided by using Debian sid instead.
2016-01-18 16:32:24 UTC
Yes. Merge the first two packages.
OK
Why are we back to using corsac’s repository? Why not use Debian sid repository and apt pinning instead?
We can but for source builds it won’t be possible to do on stable because dependencies. (for now)
/etc/sysctl.d/grsec.conf → needs a digitdigit- notation. For example 30-grsec.conf or so. Trying to foresee Debian shipping that name which would then conflict with our package.
I foresaw this and followed the number scheme used by Arch: 05-grsecurity.conf
So it would only work with KVM and for all others it would use the non-grsec kernel?
Likely and it would need testing to determine.
This is super difficult.
Another option would be to have the grsec kernel package installed but not set as the default in grub. On first run a script would run
$ grep menuentry /boot/grub/grub.cfg | cut -d “'” -f2 | grep “grsec$”
Now edit /etc/default/grub and change the GRUB_DEFAULT= line be to "Advanced options for Debian GNU/Linux> followed by the kernel version string. Put the whole things in quotes, like this: GRUB_DEFAULT=“Advanced options for Debian GNU/Linux>Debian GNU/Linux, with Linux 4.3.3-grsec”
based on a user’s choice from the first run wizard to enable default boot from a hardended kernel.
Debian GNU/Linux, with Linux 4.3.3-grsec
Hardening Debian for the Desktop Using Grsecurity | Micah Lee
What’s Debian’s config?
I’ll check.
I don’t remember off hand but could certainly figure out this again. However, as said above I hope this route can be avoided by using Debian sid instead.
Up to you it depends on what want to do with source builds.
2016-01-18 20:55:33 UTC
Why are we back to using corsac’s repository? Why not use Debian sid repository and apt pinning instead?
We can but for source builds it won’t be possible to do on stable because dependencies. (for now)
And how does corsac’s repository help with that compared to Debian sid repository?
Framed this question another way: What’s better/worse/different with corsac’s repository vs Debian sid repository?
We can but for source builds it won’t be possible to do on stable because dependencies. (for now)
Cannot work around that by downloading them from testing or sid? Or building inside a debootstrap sid chroot?
I don’t think we should install a grsecurity kernel by default for the first iteration. That change is too complex. Apt pinning what what not. At first it would be good to have lots of users test this so we can iron out any issues. Specifically not breaking Whonix for most users.
Up to you it depends on what want to do with source builds.
I think they really matter. Since you can get some security improvements only when you compile from source, and since this is for increased security, and for advanced users, there will always be demand for it. The binary downloaded kernel would not be the full solution.
Now edit /etc/default/grub
Can be avoided by using /etc/default/grub.d or /etc/grub.d? (They both work. Have a different purpose.)
So it would only work with KVM and for all others it would use the non-grsec kernel?
Likely […]
This is unacceptable as final solution. In the solution must potentially be room to make other platforms, Qubes [and VirtualBox] work also.
Anyhow. I think we reached consensus on the combined grsec-conf package already. (Combination of grsec-conf and paxctld-conf.) There should be no blocker anymore that prevents you working on this?
2016-01-18 21:00:02 UTC
I’m almost done with the exceptions list. I merged some rules to cover Tor Browser and a few other binaries that weren’t included. Changed some binary paths to reflect those on Debian…
I will link to it shortly.
With the sheer number of exceptions I’m questioning if we should just make pax softmode = 1 in grsec conf to make PaX protections opt-in. Hardly anything is covered anyhow: java, python, all gtk,qt, kde binaries web browsers and email clients are exempted.
2016-01-18 21:14:53 UTC
2016-01-18 21:25:44 UTC
And how does corsac’s repository help with that compared to Debian sid repository?
The idea was you can just use the stable version of gcc to compile without needing the versions in sid.
Cannot work around that by downloading them from testing or sid? Or building inside a debootstrap sid chroot?
Interesting. I don’t see why it shouldn’t work.
I don’t think we should install a grsecurity kernel by default for the first iteration. That change is too complex. Apt pinning what what not. At first it would be good to have lots of users test this so we can iron out any issues. Specifically not breaking Whonix for most users.
Of course. Then it would be available in developer’s only?
I think they really matter. Since you can get some security improvements only when you compile from source, and since this is for increased security, and for advanced users, there will always be demand for it. The binary downloaded kernel would not be the full solution.
Agreed. We can have our cake and eat it too with the upstreaming progress thats happened.
Can be avoided by using /etc/default/grub.d or /etc/grub.d? (They both work. Have a different purpose.)
OK.
This is unacceptable as final solution. In the solution must potentially be room to make other platforms, Qubes [and VirtualBox] work also.
Some compatibility work for grsec to work inside Xen has happened though I can’t remember where I saw it. It should work but because of Xen’s design you can’t have full grsec protection. Needs testing nothing is certain yet.
Anyhow. I think we reached consensus on the combined grsec-conf package already. (Combination of grsec-conf and paxctld-conf.) There should be no blocker anymore that prevents you working on this?
No blockers. I am done.
2016-01-18 21:45:31 UTC
2016-01-18 23:21:49 UTC
This can very well go to the testers and also the stable repository just
05-grsecurity.conf needs a license header.
paxctld.conf license?
You need debian/rules using dh-systemd. See some Whonix package that ships a systemd service as example.
/etc/paxctld.conf will be owned by another package? So we cannot overwrite it just like this. dpkg would complain about a conflict and abort installing either package. In this case, and in the absence of a ‘.d’ folder, we would have to use config-package-dev. How to do this or finding a git commit to emulate would take me longer than actually doing it. So when you are ready to not make some changes to that file for a few hours and ask me to do it, I will do it quickly.
run ‘make deb-uachl-bumpup’ to generate changelog.upstream and to add a second entry to the changelog (lintian would otherwise throw a warning that does not apply to us [[initial release does not close ITP bug]])
make sure you have lintian installed (sudo apt-get install lintian) and make sure it runs during ‘make deb-pkg’, or just run ‘make deb-pkg’ and then run lintian manually (‘lintian’). Or better, the the right env variable to make lintian fail closed during genmkfile run.
make_use_lintian=true make deb-pkg
And after we fixed all of that, try to actually install the package (make_use_lintian=true make deb-icup) and see if it’s actually working.
2016-01-19 16:01:14 UTC
needs a license header.
Its all gplv3. Do you have an example?
debian/rules using dh-systemd.
Please point to a package I can emulate.
/etc/paxctld.conf will be owned by another package?
I don’t know. I opened a bu upstream to ask and see if some of my configs can be upstreamed.
What do you think about?
With the sheer number of exceptions I’m questioning if we should just make pax softmode = 1 in grsec conf to make PaX protections opt-in. Hardly anything is covered anyhow: java, python, all gtk,qt, kde binaries web browsers and email clients are exempted.
2016-01-19 16:49:05 UTC
HulaHoop (HulaHoop):
needs a license header.
Its all gplv3. Do you have an example?
These marked two lines:
sdwdate/lib/systemd/system/sdwdate.service at 50fd9eb567da5128c53d0592ee99a75334c6efa9 · Kicksecure/sdwdate · GitHub
debian/rules using dh-systemd.
Please point to a package I can emulate.
sdwdate, control-port-filter-python, whonixcheck
/etc/paxctld.conf will be owned by another package?
I don’t know. I opened a bu upstream to ask and see if some of my configs can be upstreamed.
What do you think about?
Upstreaming is great so at some point we would not have to ship a
2016-01-19 20:54:21 UTC
2016-01-19 20:59:35 UTC
2016-01-21 17:00:00 UTC
2016-01-21 17:08:23 UTC
What does not work? The package build/install or the grsecurity kernel
If you did not reboot you need to run ‘sysctl -p’ to make sysctl.d
2016-01-21 17:10:59 UTC
2016-01-22 02:37:57 UTC
What does not work? The package build/install or the grsecurity kernel itself?
The grsec kernel with these settings. It doesn’t matter if its 05-grsecurity.conf or the default grsec.conf are changed, the settings don’t apply and so the desktop cannot boot. I restarted the system each time and i tested with sysctl restrictions turned off (a security feature that was enabled to stop code from modifying a running kernel).
You want softmode, right? So why use ‘kernel.pax.softmode=0’ instead of ‘kernel.pax.softmode=1’?
Yes I know it was set to 1.
2016-01-25 19:39:27 UTC
The problem is the Debian kernel is not compiled with any virtualization support.
I could ask for it but it won’t solve this for the other two hypervisors you want to support - unless they are custom builds which defeats the whole purpose of a binary package.
2016-01-26 22:40:30 UTC
2016-01-27 03:23:28 UTC
2016-01-27 14:30:52 UTC
2016-01-28 03:14:14 UTC
Not gonna happen. It took this long to package grsec for Debian because of their no duplicate packages policy so the patch had to be adjusted to work with the Debian flavor of the linux kernel.
The odds of them maintain different binary packages for this feature are nil.
I haven’t been successful in getting upstream to understand that enabling this option is simple. Related: They opted to disable Grsecurity’s MAC, RBAC because its “duplicate” functionality to Apparmor even though they don’t conflict…
2016-01-28 09:17:55 UTC
There is no “no duplicate package” policy in that sense. There is a “no
2016-02-05 06:15:30 UTC
2016-02-05 11:26:33 UTC
2016-02-05 15:21:06 UTC
2016-02-29 18:40:26 UTC
2016-02-29 21:43:44 UTC
2016-03-01 18:28:43 UTC
2017-04-29 16:20:02 UTC