Bug#1064044: change Debian's default umask to a more secure value such as umask 0077
Package: general Severity: wishlist Feature request: Change Debian's default umask to a more secure value such as umask 0077. Why? Quote Securing Debian Manual [1] > Debian's default umask setting is 022 this means that files (and directories) can be read and accessed by the user's group and by any other users in the system. This definition is set in the standard configuration file /etc/profile which is used by all shells. > If Debian's default value is too permissive for your system you will have to change the umask setting for all the shells. More restrictive umask settings include 027 (no access is allowed to new files for the other group, i.e. to other users in the system) or 077 (no access is allowed to new files to the members the user's group). > Finally, you should consider changing root's default 022 umask (as defined in /root/.bashrc) to a more strict umask. That will prevent the system administrator from inadvertenly dropping sensitive files when working as root to world-readable directories (such as /tmp) and having them available for your average user. Would that be reasonable change Debian's default umask to a more secure value such as umask 0077 or do you expect any breakage, would that be manageable? Cheers, Patrick [1] https://www.debian.org/doc/manuals/securing-debian-manual/ch04s11.en.html#id-1.5.14.19
Re: convention on listen port local or all network interfaces etc. - revision 2
A convention on listen port local or all network interfaces etc. would be desirable. At the moment it looks like there is no convention for where server applications are configured to listen by default, on localhost vs. all interfaces. Looks like deciding that is up to the upstream author of the software as well as the packager. Then it's up to the system administrator to decide on where the server application should listen. There is no great place for derivatives to globally modify this setting. Usually applications using Tor ephemeral hidden services such as ricochet-im, onionshare, ZeroNet, unMessage listen on localhost only. Whonix is a Debian derivative with focus on anonymity, privacy and security. To oversimplify it, we preconfigure Debian with these goals in mind. Due to Whonix's workstation, gateway split design, applications using Tor ephemeral hidden services need to listen on the workstation's external interface rather than on the workstation's localhost. A global configuration file such as `/etc/ricochet-im.conf` works for system administrators, but not for derivatives. Why is a config folder `/etc/ricochet-im.d` strongly preferred over a config file `/etc/ricochet-im.conf`? When a config file such as `/etc/ricochet-im.conf` is owned by one package `ricochet-im`, it cannot be owned by another package. If another package was to modify it using `sed` or so, then dpkg would regard that file as user modified. The problem is, next time that config file is changed by upstream, this throws an interactive dpkg conflict resolution dialog at the user, which is a usability bug. (example [2]) `sed` style config modifications are a Debian policy violation as well. So far we at Whonix had discussions with ricochet-im, onionshare, ZeroNet and unMessage. They are all interested to make their applications compatible with Whonix. However, asking each individual project to `/etc/application-specific.d` folder where Whonix then could drop a `/etc/application-specific.d/30_whonix.conf` that says `listen=10.152.152.10` is a lot duplicate effort and not that desirable for these applications because they have not yet any need for `/etc/application-specific.d/`. Having these applications auto detect Whonix also does not seem like great solution. Seems unsafe. If the auto detection code kicks in as a false positive, users would be at risk. Since it's Whonix specific and general solutions reusable by anyone are to be preferred. At least that is my interpretation of *nix philosophy. May the following convention be suggested. * Parse in lexical order. ** `/usr/lib/listen.d` ** `/usr/local/etc/listen.d` ** `/etc/listen.d` ** Optionally, custom folders ** Similar to how systemd would parse these folders. I.e. for example start with parsing `/usr/lib/listen.d/30_default.conf`, followed by `/usr/lib/listen.d/31_other.conf`, followed by `/usr/local/etc/listen.d/30_user.conf`, followed by `/etc/listen.d/30_user.conf`, followed by `/etc/listen.d/40_user.conf` and so forth. * The file used to group the configurations would be `/etc/listen.conf`, with the contents: ``` # lines starting with # are ignored # predefined include /usr/lib/listen.d/*.conf include /usr/local/etc/listen.d/*.conf include /etc/listen.d/*.conf # custom configurations may be added here ``` ** In theory, any path could be added to this file, even within `$HOME`. However, we are still uncertain of the usefulness of adding configurations to `$HOME` instead of one of the ones within `/usr/` and `/etc/`. It would make it possible to make customizations when the user does not have privileges to write outside of `$HOME`, but running a server on a system which you do not have such access seems unlikely. Feedback on this is also appreciated. * `.conf` files would contain options such as: ``` # lines starting with # are ignored # global fallback setting for all listeners listen_ip=127.0.0.1 listen_ip=10.152.152.10 listen_ip=0.0.0.0 listen_ip=UNIX-LISTEN:/path/to/.sock listen_ip=eth0 # web interfaces listen_ip_web=127.0.0.1 listen_ip_web=10.152.152.10 listen_ip_web=0.0.0.0 listen_ip_web=UNIX-LISTEN:/path/to/_web.sock listen_ip_web=eth0 # listen incoming IP listen_ip_incoming=127.0.0.1 listen_ip_incoming=10.152.152.10 listen_ip_incoming=0.0.0.0 listen_ip_incoming=UNIX-LISTEN:/path/to/_incoming.sock listen_ip_incoming=eth0 # optional application specific listen port listen_port_=15000 listen_range_=16000-17000 ``` For example... ``` # /etc/listen.d/30_default.conf listen_ip=0.0.0.0 # /etc/listen.d/50_user.conf listen_ip=127.0.0.1 ``` Would mean listen on `0.0.0.0` as well as on `127.0.0.1`. This disable listeners by previous lower priority configuration files, one could use `listen_ip=`. For example: ``` # /etc/listen.d/30_default.conf listen_ip=0.0.0.0 # /etc/listen.d/50_user.conf listen_ip= listen_ip=127.0.0.1 ``` Would result in listening on `127.0.0.1` only. This is similar to how systemd parses systemd unit files. To prevent different
Re: convention on listen port local or all network interfaces etc.
Tomas Pospisek: > Am 21.02.2017 um 01:55 schrieb Patrick Schleizer: > >> for file_name in /usr/lib/server-config.d/*.conf ; do >>file_list="$file_list $file_name" >> done >> >> for file_name in /etc/server-config.d/*.conf ; do >>file_list="$file_list $file_name" >> done >> >> for file_name in /home/.config/server-config.d/*.conf ; do >>file_list="$file_list $file_name" >> done >> >> for item in $file_list ; do >>source "$item" >> done > > I like this in principle. However, I'd rather make stuff explicit than > implicit. Implicit means you need to have a priory knowledge, explicit > means you see stuff. So for the above that would be: > > $ cat /etc/server/main.config > ... > # predefined > include /usr/lib/server/config.d/*.conf > # system config > include /etc/server/config.d/*.conf > > *t That is a great idea! Will try to keep explicit vs implicit in mind. Explicit is great. I'll be updating this convention proposal when no more comments come in. Would you suggest just a single file /etc/server/main.config? Or should there be also: - /usr/lib/server/main.config - /etc/server/main.config - /home/.config/server/main.config ? Should main.config file[s] only contain `include` statements and comments and nothing else? Best regards, Patrick
Re: convention on listen port local or all network interfaces etc.
Marco d'Itri: >> So far we at Whonix had discussions with ricochet-im, onionshare, >> ZeroNet and unMessage. They are all interested to make their >> applications compatible with Whonix. However, asking each individual >> project to `/etc/application-specific.d` folder where Whonix then could >> drop a `/etc/application-specific.d/30_whonix.conf` that says >> `listen=10.152.152.10` is a lot duplicate effort and not that desirable >> for these applications because they have not yet any need for >> `/etc/application-specific.d/`. > Indeed. This can easily be solved in a general way by implementing > systemd socket activation in these daemons. > This way you will be able to drop files in /etc/systemd/system/ to make > them bind to a specific address or interface. ricochet-im, onionshare and unMessage aren't daemons. Not comparable to to daemons like apache that get started by the init system. These are applications to be started by the user on demand. These are more like Pidgin / XChat etc. Therefore socket activation may not be the best tool here? Best regards, Patrick
convention on listen port local or all network interfaces etc.
A convention on listen port local or all network interfaces etc. would be desirable. At the moment it looks like there is no convention for where server applications are configured to listen by default, on localhost vs. all interfaces. Looks like deciding that is up to the upstream author of the software as well as the packager. Then it's up to the system administrator to decide on where the server application should listen. There is no great place for derivatives to globally modify this setting. Usually applications using Tor ephemeral hidden services such as ricochet-im, onionshare, ZeroNet, unMessage listen on localhost only. Whonix is a Debian derivative with focus on anonymity, privacy and security. To oversimplify it, we preconfigure Debian with these goals in mind. Due to Whonix's workstation, gateway split design, applications using Tor ephemeral hidden services need to listen on the workstation's external interface rather than on the workstation's localhost. A global configuration file such as `/etc/ricochet-im.conf` works for system administrators, but not for derivatives. Why is a config folder `/etc/ricochet-im.d` strongly preferred over a config file `/etc/ricochet-im.conf`? When a config file such as `/etc/ricochet-im.conf` is owned by one package `ricochet-im`, it cannot be owned by another package. If another package was to modify it using `sed` or so, then dpkg would regard that file as user modified. The problem is, next time that config file is changed by upstream, this throws an interactive dpkg conflict resolution dialog at the user, which is a usability bug. (example [x]) `sed` style config modifications are a Debian policy violation as well. So far we at Whonix had discussions with ricochet-im, onionshare, ZeroNet and unMessage. They are all interested to make their applications compatible with Whonix. However, asking each individual project to `/etc/application-specific.d` folder where Whonix then could drop a `/etc/application-specific.d/30_whonix.conf` that says `listen=10.152.152.10` is a lot duplicate effort and not that desirable for these applications because they have not yet any need for `/etc/application-specific.d/`. Having these applications auto detect Whonix also does not seem like great solution. Seems unsafe. If the auto detection code kicks in as a false positive, users would be at risk. Since it's Whonix specific and general solutions reusable by anyone are to be preferred. At least that is my interpretation of *nix philosophy. May the following convention be suggested. * Parse in lexical order. ** `/usr/lib/server-config.d` ** `/etc/server-config.d` ** `~/.config/server-config.d` ** Similar to how systemd would parse these folders. I.e. for example start with parsing `/usr/lib/server-config.d/30_default.conf`, followed by `/usr/lib/server-config.d/31_other.conf`, followed by `/etc/server-config.d/30_user.conf`, followed by `/etc/server-config.d/40_user.conf` and so forth. * The pseudo code in shell / bash: ``` for file_name in /usr/lib/server-config.d/*.conf ; do file_list="$file_list $file_name" done for file_name in /etc/server-config.d/*.conf ; do file_list="$file_list $file_name" done for file_name in /home/.config/server-config.d/*.conf ; do file_list="$file_list $file_name" done for item in $file_list ; do source "$item" done ``` * config options: ``` # lines starting with # are ignored # global fallback setting for all listeners listen_ip=127.0.0.1 listen_ip=10.152.152.10 listen_ip=0.0.0.0 listen_ip=UNIX-LISTEN:/path/to/.sock listen_ip=eth0 # web interfaces listen_ip_web=127.0.0.1 listen_ip_web=10.152.152.10 listen_ip_web=0.0.0.0 listen_ip_web=UNIX-LISTEN:/path/to/_web.sock listen_ip_web=eth0 # listen incoming IP listen_ip_incoming=127.0.0.1 listen_ip_incoming=10.152.152.10 listen_ip_incoming=0.0.0.0 listen_ip_incoming=UNIX-LISTEN:/path/to/_incoming.sock listen_ip_incoming=eth0 # optional application specific listen port listen_port_=15000 listen_range_=16000-17000 ``` For example... ``` # /etc/server-config.d/30_default.conf listen_ip=0.0.0.0 # /etc/server-config.d/50_user.conf listen_ip=127.0.0.1 ``` Would mean listen on `0.0.0.0` as well as on `127.0.0.1`. This disable listeners by previous lower priority configuration files, one could use `listen_ip=`. For example: ``` # /etc/server-config.d/30_default.conf listen_ip=0.0.0.0 # /etc/server-config.d/50_user.conf listen_ip= listen_ip=127.0.0.1 ``` Would result in listening on `127.0.0.1` only. This is similar to how systemd parses systemd unit files. To prevent different applications to parse the configuration differently, to avoid unexpected results, it would be useful to have a python library and command line tool to query it. Any questions? Any suggestions? What do you think? [x]: https://www.whonix.org/wiki/Whonix_Configuration_Files#dpkg_interactive_conflict_resolution_dialog
convention on listen port local or all network interfaces etc.
A convention on listen port local or all network interfaces etc. would be desirable. At the moment it looks like there is no convention for where server applications are configured to listen by default, on localhost vs. all interfaces. Looks like deciding that is up to the upstream author of the software as well as the packager. Then it's up to the system administrator to decide on where the server application should listen. There is no great place for derivatives to globally modify this setting. Usually applications using Tor ephemeral hidden services such as ricochet-im, onionshare, ZeroNet, unMessage listen on localhost only. Whonix is a Debian derivative with focus on anonymity, privacy and security. To oversimplify it, we preconfigure Debian with these goals in mind. Due to Whonix's workstation, gateway split design, applications using Tor ephemeral hidden services need to listen on the workstation's external interface rather than on the workstation's localhost. A global configuration file such as `/etc/ricochet-im.conf` works for system administrators, but not for derivatives. Why is a config folder `/etc/ricochet-im.d` strongly preferred over a config file `/etc/ricochet-im.conf`? When a config file such as `/etc/ricochet-im.conf` is owned by one package `ricochet-im`, it cannot be owned by another package. If another package was to modify it using `sed` or so, then dpkg would regard that file as user modified. The problem is, next time that config file is changed by upstream, this throws an interactive dpkg conflict resolution dialog at the user, which is a usability bug. (example [x]) `sed` style config modifications are a Debian policy violation as well. So far we at Whonix had discussions with ricochet-im, onionshare, ZeroNet and unMessage. They are all interested to make their applications compatible with Whonix. However, asking each individual project to `/etc/application-specific.d` folder where Whonix then could drop a `/etc/application-specific.d/30_whonix.conf` that says `listen=10.152.152.10` is a lot duplicate effort and not that desirable for these applications because they have not yet any need for `/etc/application-specific.d/`. Having these applications auto detect Whonix also does not seem like great solution. Seems unsafe. If the auto detection code kicks in as a false positive, users would be at risk. Since it's Whonix specific and general solutions reusable by anyone are to be preferred. At least that is my interpretation of *nix philosophy. May the following convention be suggested. * Parse in lexical order. ** `/usr/lib/server-config.d` ** `/etc/server-config.d` ** `~/.config/server-config.d` ** Similar to how systemd would parse these folders. I.e. for example start with parsing `/usr/lib/server-config.d/30_default.conf`, followed by `/usr/lib/server-config.d/31_other.conf`, followed by `/etc/server-config.d/30_user.conf`, followed by `/etc/server-config.d/40_user.conf` and so forth. * The pseudo code in shell / bash: ``` for file_name in /usr/lib/server-config.d/*.conf ; do file_list="$file_list $file_name" done for file_name in /etc/server-config.d/*.conf ; do file_list="$file_list $file_name" done for file_name in /home/.config/server-config.d/*.conf ; do file_list="$file_list $file_name" done for item in $file_list ; do source "$item" done ``` * config options: ``` # lines starting with # are ignored # global fallback setting for all listeners listen_ip=127.0.0.1 listen_ip=10.152.152.10 listen_ip=0.0.0.0 listen_ip=UNIX-LISTEN:/path/to/.sock listen_ip=eth0 # web interfaces listen_ip_web=127.0.0.1 listen_ip_web=10.152.152.10 listen_ip_web=0.0.0.0 listen_ip_web=UNIX-LISTEN:/path/to/_web.sock listen_ip_web=eth0 # listen incoming IP listen_ip_incoming=127.0.0.1 listen_ip_incoming=10.152.152.10 listen_ip_incoming=0.0.0.0 listen_ip_incoming=UNIX-LISTEN:/path/to/_incoming.sock listen_ip_incoming=eth0 # optional application specific listen port listen_port_=15000 listen_range_=16000-17000 ``` For example... ``` # /etc/server-config.d/30_default.conf listen_ip=0.0.0.0 # /etc/server-config.d/50_user.conf listen_ip=127.0.0.1 ``` Would mean listen on `0.0.0.0` as well as on `127.0.0.1`. This disable listeners by previous lower priority configuration files, one could use `listen_ip=`. For example: ``` # /etc/server-config.d/30_default.conf listen_ip=0.0.0.0 # /etc/server-config.d/50_user.conf listen_ip= listen_ip=127.0.0.1 ``` Would result in listening on `127.0.0.1` only. This is similar to how systemd parses systemd unit files. To prevent different applications to parse the configuration differently, to avoid unexpected results, it would be useful to have a python library and command line tool to query it. Any questions? Any suggestions? What do you think? [x]: https://www.whonix.org/wiki/Whonix_Configuration_Files#dpkg_interactive_conflict_resolution_dialog
