-
Notifications
You must be signed in to change notification settings - Fork 51
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Non-Identifiable and Generic Issue Banners that include the Recommended Keywords #167
Conversation
etc/issue.d/20_security-misc
Outdated
@@ -0,0 +1,2 @@ | |||
By continuing to connect to this system, you consent to the owner storing a log of all activity. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
log of all activity
this wording could create some FUD or at least questions what sort of logging mechanisms there are.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean by users who simply install security-misc (or Kicksecure) and then wonder what this is about.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- 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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
/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:
|
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. |
Lucky for us, actually no. They can still do their thing. We do not touch the This results in the following: Let's say Whonix has the following /etc/issue file content:
By adding our config file under
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. |
Yes, it's possible to prepend / append using But: #167 (review) I didn't find Debian references for |
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. |
https://github.com/CISOfy/lynis/blob/master/include/tests_banners
lynis wants to see 5 keywords. But it seems it does not consider |
The message has been updated to be less direct and vague as you wished. Please check the new version. |
As per https://manpages.debian.org/testing/util-linux/getty.8.en.html
Also
Will remove. |
Done. |
For SSH, See also existing folder That would be "patches welcome". |
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 likeWelcome 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.