Non-Identifiable and Generic Issue Banners that include the Recommended Keywords

[monsieuremre]

This may or may not be desirable for this project. First short information. /etc/issue is a file that is displayed before someone tries to log in from console. Respectively /etc/issue.net is displayed before someone tries logging in remotely to the system over the internet. These do not display on graphical login. On Debian by default, the issue banners are empty. This is actually not that bad considering on other Linux systems, it is common to have default issues like Welcome to openSUSE or whatever. So our system does not leak system information in the banners. This is good. But that is because the issues are completely empty. There are some 'keywords' that are recommended to have in the banners. It is very common practice to have legal banners on servers (there rarely isn't any banners on servers or iot devices). These are mostly in the line of 'beware, I know you are here, and I might do stuff'. This is at the very worst still some sort of deterrance. I think it won't hurt that we follow the recommended guidelines and add these to our default banners. If someone tries to connect to the system, the banner that I use here in my project will display.

A miniscule improvement that brings no harm.

[adrelanos]

log of all activity this wording could create some FUD or at least questions what sort of logging mechanisms there are.

[adrelanos]

I mean by users who simply install security-misc (or Kicksecure) and then wonder what this is about.

[monsieuremre]

This is very standard stuff and I don't think it would come as uncertain. If you want we can soften it a little like:

By continuing to connect to this system, you consent that the owner may keep a log of all your activites.

[adrelanos]

• A) Does it need to be a standardized message that some other system is already using to blend-in / superficially pretend to be another operating system?
  • If so, please show sources for these existing / "standardized" messages to choose from.
• B) Or can it be a custom message?
  • Easier. I am sure I could come up with a message that is not (or minimal levels) generating FUD.

[adrelanos]

Unauthorized access is strictly prohibited and may result in legal consequences. By continuing to use this system, you acknowledge and consent to the possibility of activity logging if the owner has enabled this feature.

[adrelanos]

/etc/issue is non-empty on Debian by default. /etc/issue is owned by base-files Debian package.

These are actually used for branding and usability in Kicksecure, Whonix.

Looking through derivative-maker source code:

find . -type f -not -iwholename '*.git*'

./packages/whonix/whonix-base-files/etc/issue.whonix
./packages/whonix/anon-gw-base-files/etc/issue.d/30_whonix-gateway.issue
./packages/whonix/anon-ws-base-files/etc/issue.d/30_whonix-workstation.issue
./packages/kicksecure/kicksecure-base-files/etc/issue.kicksecure

[adrelanos]

Maybe security-misc could set /etc/issue to empty (by using config-package-dev). [1]

---

Packaging issues:

kicksecure-base-files and whonix-base-files are currently doing that. These two packages would have to stop doing that.

Stopping to use config-package-dev displace in these packages and starting to do that in security-misc... Not sure if that would clash during upgrade and break APT. Maybe I could remove the config-package-dev hide during this Debian stable release cycle and move that to security-misc for Debian stable + 1.

---

[1] This would be to avoid leaking operating system name and version on the virtual terminal login screen.

[monsieuremre]

kicksecure-base-files and whonix-base-files are currently doing that. These two packages would have to stop doing that.

Lucky for us, actually no. They can still do their thing. We do not touch the /etc/issue or the /etc/issue.net files here. The distro manages them as usual. We add our config files under the directories /etc/issue.d and /etc/issue.net.d.

This results in the following:

Let's say Whonix has the following /etc/issue file content:

Hello welcome to whonix, a very cool os

By adding our config file under /etc/issue.d, the following issue banner would display:

Hello welcome to whonix, a very cool os

By continuing to connect to this system, you consent to the owner storing a log of all activity.

So we basically just add it on top of the already existing issue. Which in debian by default is empty, just checked on a default install. If it is non-empty in whonix, or kicksecure, still no problem. We just add on top, so it won't interfere with anything.

On a side-note, I would recommend not mentioning the os name on the issue for whonix. Just to leak less information. But this is a nitpick.

[adrelanos]

Yes, it's possible to prepend / append using /etc/issue.d folder.

But: #167 (review)

---

I didn't find Debian references for /etc/issue.net.d folder.

[monsieuremre]

If I'm not mistaken, both folders are created automatically on a default opensuse tumbleweed install. I have to test this again. But if what I recall is correct, then the folder has to be valid and debian can't be any different.

[adrelanos]

https://github.com/CISOfy/lynis/blob/master/include/tests_banners

    BANNER_FILES="${ROOTDIR}etc/issue ${ROOTDIR}etc/issue.net ${ROOTDIR}etc/motd"
    LEGAL_BANNER_STRINGS="audit access authori condition connect consent continu criminal enforce evidence forbidden intrusion law legal legislat log monitor owner penal policy policies privacy private prohibited record restricted secure subject system terms warning"

Result: Found ${COUNT} key words (5 or more suggested), to warn unauthorized users

lynis wants to see 5 keywords.

But it seems it does not consider .d folders. That would be a lynis bug that might need reporting.

[monsieuremre]

The message has been updated to be less direct and vague as you wished. Please check the new version.

[adrelanos]

As per https://manpages.debian.org/testing/util-linux/getty.8.en.html

.issue extension (file extension) needed. Will add.

Also /usr/lib/issue.d is supported. Will move.

I didn't find Debian references for /etc/issue.net.d folder.

Will remove.

[adrelanos]

Done.

[adrelanos]

For SSH, /usr/lib/motd.d/ might be usable. -> https://manpages.debian.org/bookworm/libpam-modules/pam_motd.8.en.html

See also existing folder /etc/update-motd.d in Kicksecure. -> https://wiki.debian.org/motd

That would be "patches welcome".