search

Kicksecure / security-misc

Kernel Hardening; Protect Linux User Accounts against Brute Force Attacks; Improve Entropy Collection; Strong Linux User Account Separation; Enhances Misc Security Settings - https://www.kicksecure.com/wiki/Security-misc
https://www.kicksecure.com/wiki/Impressum
Other
517 stars 51 forks source link

`Depends:` vs `Recommends:` vs none #169

Closed adrelanos closed 11 months ago

adrelanos commented 1 year ago

Do we really need Depends:? This makes it difficult to remove the package for users.

Perhaps Recommends: is sufficient? Not ideal.

Or nothing.

Why? Because security-misc shouldn't be attempting to be a Linux distribution such as Kicksecure that installs by a number of pre-installed applications.

references:

monsieuremre commented 1 year ago

I am for depends.

Recommends is too weak and we configure the config files. Security-misc does not try to be a distribution in my opinion. If it becomes a vital component of kicksecure, that is still ok. I see no problem. I also think these packages are relatively minimalistic.

adrelanos commented 1 year ago

Depends in security-misc would result in usbguard being installed by default in Kicksecure for VirtualBox VM images and these don't come with USB enabled by default so that would be a superfluous package. Everybody without USB couldn't remove this package without getting trouble with security-misc.

The usbguard config suggestion seems suitable here but the depends can go to kicksecure-meta-packages.

Maybe in

not sure yet.

adrelanos commented 1 year ago

Depends: would be inappropriate as per Debian policy.

Packaging is done with Debian policy compliance in mind. Packages by Kicksecure, Whonix are already lintian --pedantic clean as much as feasible.

monsieuremre commented 1 year ago

At least recommend them. I don't support moving them to another package. Everything that is security-misc should be handled here. This provides platform indepence. It shoud be kept possible to install this on debian and have a hardened system.

adrelanos commented 1 year ago

I exactly don't want to replicate Kicksecure in security-misc. There's a structure.

If starting to add security enhancing recommended packages which then would become candidates for Recommends:.

This is just security-misc. Part of the Kicksecure project. Other major, complex code bases (examples like LKRG, tirdad) will stay in their own code repositories. This is to avoid code duplication.

As for platform independence, security-misc currently depends on apparmor-profile-dist, a package by Kicksecure, which isn't a great dependency and maybe avoidable.

Maybe the whole apparmor-profile-dist could be avoided. (https://github.com/roddhjav/apparmor.d/issues/251)

Even genmkfile is no longer a build dependency.

security-misc also depends on helper-scripts, another package by Kicksecure. If a Debian (or other distribution) maintainer wanted to add security-misc to their distribution then both packages would need to be uploaded. If there is an actual distribution maintainer interested in this, and this being a major obstacle then maybe this dependency could also be avoided.

Uploading to Debian or a Debian derivative might be relatively simple in theory because the Debian packaging files already exist, are used and tested for years in Kicksecure, Whonix and maybe only minor changes required to adhere with Debian policy. To be found upon the review of an actual distribution maintainer.

An acceptable Recommends: could be kicksecure-dependencies-cli and/or kicksecure-recommended-cli.

The scope is somewhat hard to define for security-misc. Ideally, security-misc which tends to get a bit messy, wouldn't need to exist.

Settings such as https://github.com/Kicksecure/security-misc/blob/master/etc/default/grub.d/40_distrust_cpu.cfg would ideally be the upstream default but as long as they're not, it's not feasible to have a dedicated package for all of these small security tweaks. (Debian FTP masters won't accept lots of single file content packages. So that's not a good packaging style.)

If any scope defining / restricting readme edits are suggested, happy to have a look at a PR.

monsieuremre commented 1 year ago

As for platform independence, security-misc currently depends on apparmor-profile-dist, a package by Kicksecure, which isn't a great dependency and maybe avoidable.

Yes. This please. Whenever I build it in a debian vm, I also have to enable the kicksecure repos because it wants to install those packages too.

I think depending on libpam-tmpdir or usbguard is way more acceptable tho. I think it is better in fact. Because they are standard debian packages that should be in theory available in any debian system and derivatives.

adrelanos commented 1 year ago

As for platform independence, security-misc currently depends on apparmor-profile-dist, a package by Kicksecure, which isn't a great dependency and maybe avoidable.

Yes. This please. Whenever I build it in a debian vm, I also have to enable the kicksecure repos because it wants to install those packages too.

That is https://github.com/roddhjav/apparmor.d/issues/251 and also suitable for contributions to speed this task up. (Merging apparmor-profile-dist stuff elsewhere so that package can be deprecated.)

adrelanos commented 11 months ago

https://github.com/Kicksecure/security-misc#project-scope-of-application-specific-hardening