Bug#702030: ideas for implementation

[Patrick Schleizer]

Hi!

intrigeri:
 Patrick Schleizer wrote (09 Jun 2014 14:20:15 GMT) :
 I have two ideas on how to implement this and might eventually even be
 able to submit patches for this.
 
 I like reading this. Thanks for working on it! :)
 
 1) A clean solution, that can be implemented in the grub-common package:
 
 In /etc/grub.d/10_linux it could be attempted to run aa-status and if it
 exits 0, the following line
 [...]
 could be extended with
apparmor=1 security=apparmor
 
 It looks like the user story you have in mind to enable AppArmor
 permanently would then be:

   * in GRUB menu, manually enable AppArmor

Absolutely not.

   * boot Debian
   * run update-grub
   * now AppArmor is enabled by default
 
 Right?

[Since your solution is simpler and better, and I had this already
written, this is just FYI maybe.]

No, I was proposing a patch for /etc/grub.d/10_linux in the grub-common.

Currently:

  message=$(gettext_printf Loading Linux %s ... ${version})
  cat  EOF
echo'$message'
linux   ${rel_dirname}/${basename} root=${linux_root_device_thisversion}
ro ${args}
EOF

Proposed:

I had something in mind like this. Untested. Needs more thought. Some
useless code just to express the idea.

  which aa-status /dev/null 21
  if [ $? = 0 ]; then
aa-status /dev/null 21
  if [ $? = 0 ]; then
  # AppArmor enabled, let's keep it.
  maybe_apparmor=apparmor=1 security=apparmor
fi
if [ $? = 2 ]; then
  # AppArmor disabled by user with /etc/init.d/apparmor teardown.
  # Leave it disabled.
  maybe_apparmor=
fi
if [ $? = 3 ]; then
  # AppArmor not enabled in kernel.
  # Let's enable it.
  maybe_apparmor=apparmor=1 security=apparmor
fi
  else
maybe_apparmor=
  fi
  message=$(gettext_printf Loading Linux %s ... ${version})
  cat  EOF
echo'$message'
linux   ${rel_dirname}/${basename} root=${linux_root_device_thisversion}
ro ${maybe_apparmor} ${args}

Imagined like this:
1) sudo apt-get install apparmor
2) apparmor automatically gets enabled. Seems to be the Debian way. If
you install any daemons, most are automatically started.
3) /etc/grub.d/10_linux does the magic to enable apparmor in grub.cfg,
so it gets enabled on next reboot.
4) Maybe users who want to disable apparmor while leaving the apparmor
package installed could use apparmor=0 security= in /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT.
5) Maybe we can detect if users did run /etc/init.d/apparmor teardown
and not enable apparmor on next update-grub as well. Maybe
/etc/init.d/apparmor should run update-grub.

 My main problem with that it turns the current (possibly temporary,
 e.g. for debugging) system state into the permanent one. This seems
 potentially very confusing to users.
 
 E.g. if I boot Debian while manually disabling AppArmor for some
 reason, and then e.g. upgrade the Linux kernel, then update-grub is
 automatically run, and AppArmor will be disabled for the following
 boot. That's not what I would expect to happen. Same for the opposite
 story, if I decide to try AppArmor once and run apt upgrade, I don't
 expect my one-shot decision to be silently turned into
 a permanent one.

I am not sure I understand.

 2) A less clean solution that can be implemented in the apparmor package:
 
 Create a script /etc/grub.d/39_apparmor, that searches
 /boot/grub/grub.cfg for [...]
 
 I don't think we want to go into that: parsing and patching grub.cfg
 in a safe and robust way is hard. Maybe the Augeas lens shipped in
 augeas-lenses is good enough to do so *now*, but it's hard to be sure
 that it will always remain that good.

Valid point.

 Anyway, I eventually took time to look at how update-grub works, and
 I think I've found a clean solution to this problem: grub-mkconfig
 sources ${sysconfdir}/default/grub.d/*.cfg after sourcing
 ${sysconfdir}/default/grub, so all we have to do is ship
 /etc/default/grub.d/apparmor.cfg, that would inject what we want into
 GRUB_CMDLINE_LINUX. May you please test this?

Requires Debian Jessie.

It works! Great solution!

Shouldn't we use a number in front of the config file such as
/etc/default/grub.d/10_apparmor.cfg, to get a useful order and to make
it simpler for users to overrule it?

Could you add the /etc/default/grub.d/10_apparmor.cfg config file to the
apparmor package then please?

 I don't think we want to turn AppArmor on without at least
 *one* conscious decision from the user,

I view sudo apt-get install apparmor as my conscious decision and
would expect AppArmor getting enabled. As far I understand the debian
way is install a package = enable it's functionality (such as when you
install a package containing a daemon [ex: apache2] it usually gets
automatically started by default.

 I've seen packages
 gratuitously depend on apparmor (see e.g. #751452), merely because
 they're shipping a profile

Agreed with your bug report. Sounds like an easy to fix, grave bug
[making the package unfit for release

Bug#758228: please provide /usr/bin/visual

[Patrick Schleizer]

Package: kwrite
Severity: wishlist

Dear maintainer,

there already is,
- $EDITOR environment variable (honored by sensible-editor),
- as well as /usr/bin/editor (managed by debian alternatives) (honored
by sensible-editor).
- as well as /usr/bin/gnome-text-editor,
- as well as $VISUAL environment variable (honored by sensible-editor)

However, there is no,
- /usr/bin/visual (managed by debian alternatives) yet. (Hopefully in
future honored by sensible-editor.)

Please consider inclusion of the following debian/kwrite.prerm as well
as debian/kwrite.postinst, that would implement this.

You might be asking yourself, what would /usr/bin/visual be useful for?

Often Debian/Linux centric instructions to do X include edit file
/etc/xyz with root rights. This is quite hard for newbies, because they
don't know the name of which (visual) editor came with their flavor of
Debian preinstalled.

Instead of using instructions:
   sudo nano /etc/xyz
or:
   kdesudo kwrite /etc/xyz
Ideally, instructions could use a generic:
   sensible-su sensible-editor /etc/xyz

If the user was using a graphical environment, sensible-su would either
start gksu or kdesudo as well as whatever graphical text editor is
installed (such as kwrite). Or for non-graphical environments, it would
choose sudo as well as the installed non-visual editor (ex: nano).

I am planing on writing sensible-su as well as writing a small patch for
sensible-editor. But before, visual text editors need to provide
/usr/bin/visual.

Thank you for your consideration!

Cheers,
Patrick

-

debian/kwrite.prerm

#!/bin/sh

set -e

case $1 in
  remove|upgrade|deconfigure)
update-alternatives --remove visual /usr/bin/kate
;;

esac

#DEBHELPER#

-

debian/kwrite.postinst

#!/bin/sh

set -e

if [ $1 = configure ]; then
update-alternatives \
--install /usr/bin/visual \
visual /usr/bin/kate 40 \
--slave /usr/share/man/man1/visual.1.gz \
visual.1.gz /usr/share/man/man1/kate.1.gz
fi

#DEBHELPER#


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754730: packages should not depend on apparmor

[Patrick Schleizer]

Package: lintian
Severity: wishlist

Dear lintian maintainers,

no package should depend on apparmor. Please add a lintian check, that
reports an error, should a package depend on apparmor.

Why?

Before we can automatically enable AppArmor when the userspace tools are
installed, AppArmor maintainer intrigeri said, we must make sure, that
no packages depend on AppArmor, so AppArmor does not get installed even
though the user does not wish this. [1]

#702030 is currently blocked by this wishlist request.

Could you implement this check please?

Cheers,
Patrick

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702030


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#702030: ideas for implementation

[Patrick Schleizer]

Hi!

intrigeri:
 Shouldn't we use a number in front of the config file such as
 /etc/default/grub.d/10_apparmor.cfg, to get a useful order and to make
 it simpler for users to overrule it?
 
 Yes, ordering requires more thought, and a survey of how other
 packages that ship snippets into /etc/default/grub.d/ do. Are you up
 to it?

Yes.

search engine:
site:debian.org /etc/default/grub.d

packages content search:
https://packages.debian.org/search?searchon=contentskeywords=grub.dmode=filenamesuite=unstablearch=any

Looks like we're the first ones to ship a /etc/default/grub.d snippet. I
guess the arbitrarily chosen /etc/default/grub.d/10_apparmor.cfg is
fine. It allows others to easily hook into it earlier or later.

If you wish I can start a discussion on the Debian grub maintainers
mailing list.

 Maybe a Lintian warning raised when a package depends on
 the apparmor one, and it's not on some whitelist of packages that
 really need to depend on it, would be enough to catch most of these
 problems, though.
 
 Good idea.
 
 Are you interested in working on this? At least filing a wishlist bug
 against Lintian, describing the need, and marking #702030 as blocked
 by that other bug would be a good start.

Done:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754730

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754730: [lintian] Moreinfo

[Patrick Schleizer]

Hi bastien!

Thank you for taking this!

 Could we get a tag description ?

package-depends-recommends-on-apparmor

 Something what would explain why and how to fix your package ?

Package must neither depend nor recommend apparmor, because it would not
only enable AppArmor for this package, but for any packages shipping an
AppArmor profile, which might have unwanted effects. Enabling AppArmor
should require at least one conscious decision by the user.

Removing apparmor dependency or recommendation will fix this error.

If you are shipping an AppArmor profile, add apparmor to Suggests.

If there is a valid reason for this dependency or recommendation, please
override the tag.

 Moreover it seems that I should whitelist:
 apparmor-{utils,profiles,profiles-extra}

Please do.

[Feel free to change tag / explanation. I don't have a strong opinion
there. Whatever you feel appropriate.]

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754744: forbid most packages to depend on or recommend apparmor

[Patrick Schleizer]

Package: debian-policy
Severity: wishlist

Hi!

Suggested policy addition:

Do not depend on or recommend the apparmor package

Packages must neither depend on nor recommend apparmor, because it would
not only enable AppArmor for this package, but for any packages shipping
an AppArmor profile, which might have unwanted effects. Enabling
AppArmor should require at least one conscious decision by the user.

If you are shipping an AppArmor profile, add apparmor to Suggests.

apparmor-{utils,profiles,profiles-extra} and other packages where this
is useful are exceptions.

Reason:

Before we can automatically enable AppArmor when the userspace tools are
installed, AppArmor maintainer intrigeri said, we must make sure, that
no packages depend on AppArmor, so AppArmor does not get installed even
though the user does not wish this. [1]

Other:

Bastien ROUCARIES would implement this into lintian and asked me to
report this against policiy. [2]

Feel free to change wording / etc. I don't have a strong opinion
there. Whatever you feel appropriate.

Cheers,
Patrick

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702030
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754730


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#754730: [lintian] Moreinfo

[Patrick Schleizer]

Bastien ROUCARIES:
 Could you also open a bug agaisnt policy ? It will help to have reference.

Done:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=754744


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750848: add openvpn to init script Should-Start

[Patrick Schleizer]

Package: tor

Dear Maintainer,

could you modify Tor's init script line

# Should-Start:  $syslog

with

# Should-Start:  $syslog openvpn

please?

This would aid users who want to connect to a VPN before connecting to
Tor, because then the Tor daemon would start a little later, if and only
if openvpn is installed.

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750848: add openvpn to init script Should-Start

[Patrick Schleizer]

intrigeri:
 Am I wrong in thinking that if we add this line, then we're making
 life harder for those who want to run OpenVPN *on top* of Tor?

To my knowledge, one cannot route OpenVPN though Tor without using
Virtual Machines or multiple physical computers. (OpenVPN has no socks
proxy support and mechanisms such as torsocks won't work.)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#750848: add openvpn to init script Should-Start

[Patrick Schleizer]

intrigeri:
 Patrick Schleizer wrote (07 Jun 2014 15:11:10 GMT) :
 (OpenVPN has no socks proxy support and mechanisms such as torsocks
 won't work.)
 
 openvpn(8) mentions a socks-proxy option, and a simple web search
 shows that plenty of people seem to be happily using it.

I stand corrected and thereby withdraw my suggestion.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#702030: ideas for implementation

[Patrick Schleizer]

Dear AppArmor Maintainers,

I have two ideas on how to implement this and might eventually even be
able to submit patches for this.

1) A clean solution, that can be implemented in the grub-common package:

In /etc/grub.d/10_linux it could be attempted to run aa-status and if it
exits 0, the following line

   linux${rel_dirname}/${basename}
root=${linux_root_device_thisversion} ro ${args}

could be extended with

   apparmor=1 security=apparmor

i.e. have some $maybe_apparmor before ${args}.

2) A less clean solution that can be implemented in the apparmor package:

Create a script /etc/grub.d/39_apparmor, that searches
/boot/grub/grub.cfg for

menuentry 'Debian GNU/Linux, with Linux *' --class debian

linux   /boot/vmlinuz-* root=UUID=* ro

and injects

   apparmor=1 security=apparmor

at the end.

Please tell me what you think.

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#702030: ideas for implementation

[Patrick Schleizer]

intrigeri:
 Hi,
 
 Patrick Schleizer wrote (13 Jul 2014 18:45:42 GMT) :
 Looks like we're the first ones to ship a /etc/default/grub.d snippet. I
 guess the arbitrarily chosen /etc/default/grub.d/10_apparmor.cfg is
 fine. It allows others to easily hook into it earlier or later.
 
 I suggest 50_apparmor.cfg, that leaves even more room before, and
 enough after.

This is more a question of artistic freedom. Fine with me either way. :)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#763164: (no subject)

[Patrick Schleizer]

 I have upgraded to bash 4.3-11 and this problem is no longer reproducible.

 [...]

 I believe this bug can be closed.

I don't think this bug should be closed. Debian's wheezy repository,
that currently provides 4.2+dfsg-0.1+deb7u3 is still affected.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#776152: provide meaningful exit codes for network failures

[Patrick Schleizer]

Package: apt
Severity: important

When apt-get update fails the program exits with a 0 status.
It would be useful if it exited with a non-zero status in that case
(or if there were a switch to tell it to do so).

This is similar to bug 41053 [1] from 1999, that says it's fixed, but it
doesn't say how it was fixed and it's apparently unfixed.

See output (shortened that a little).

 sudo apt-get update
   Could not resolve 'ecurity.debian.org'
 Hit http://ftp.us.debian.org wheezy Release

 Reading package lists... Done
 W: Failed to fetch
http://ecurity.debian.org/dists/wheezy/updates/Release.gpg  Could not
resolve 'ecurity.debian.org'

 W: Some index files failed to download. They have been ignored, or old
ones used instead.
 ~ $ echo $?
 0

(For demonstration purposes, I just added a defunct deb line
deb http://ecurity.debian.org wheezy/updates main contrib non-free)

Detecting such situations in scripts is important. At least if you
really care if some extra repository gets used during a build script or
if you care an image to be build as verifiable / reproducible as possible.

Otherwise and adversary could just prevent one from connecting to a
repository one cares to received upgrades from (such as
security.debian.org), which would effectively render apt-get's security
check for expired release files (valid-until field) [2] [3] ineffective.

There is also another issue related to exit codes. [4]

Cheers,
Patrick

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=41053
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=499897
[3]
http://blog.ganneff.de/blog/2008/09/23/valid-until-field-in-release-f.html
[4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745735


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778357: audit 'apt-get update' exit codes

[Patrick Schleizer]

Julian Andres Klode:
 The results are meaningful. 0 indicates success or transient error, whereas
 other values indicate a persistent error.
 
 Stuff like gpg errors are transient, they are expected to happen during
 mirror updates due to the repository format.

If an adversary mounts a denial of service, indefinite freeze or
rollback attack, the error (network or gpg failure) would not be
transient, but persistent.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#778357: audit 'apt-get update' exit codes

[Patrick Schleizer]

Package: apt
Severity: important
X-Debbugs-CC: hol...@layer-acht.org,p...@debian.org

When apt-get update fails the program under some conditions exits with
a 0 status. It would be useful if it exited with a non-zero status in
that case (or if there were a switch to tell it to do so).

Since there is already...

- provide meaningful exit codes for network failures
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776152

and

- apt: Provide meaningful exit codes for gpg failures
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745735

That have been found more or less by trial and error... I am wondering,
if there are any other situations, where this could happen.

Perhaps while you're at #776152 and #745735, could you please check if
there are other cases, where apt-get exits with a 0 status, where it
should exit with a non-zero status?

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774888: please provide an option to hide or deactivate all the noisy, scary warnings during boot

[Patrick Schleizer]

Package: apparmor-profiles
Severity: important

When having the apparmor-profiles package installed, but not enabled all
the profiles enforced by default, there are more than 20 warnings, such as:

 Warning from /etc/apparmor.d/usr.sbin/traceroute
(/etc/apparmor.d/usr.sbin.traceroute line 29): profile
/usr/{sbin/traceroute,traceroute.rb} network rules not enforced
failed!

This was the reason for the Debian derivative distribution Whonix to
decide to no longer install the apparmor-profiles package by default.
There are simply too many of these messages during boot. Just noisy. And
scary. Produced lots of concerned questions.

It would be nice if there was an option to disable these messages during
boot. Or if you could omit them.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#774888: [pkg-apparmor] Bug#774888: please provide an option to hide or deactivate all the noisy, scary warnings during boot

[Patrick Schleizer]

Those warnings are fixed in testing indeed. Sorry for the noise.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780970: [bash] exported bash functions broken in chroot

[Patrick Schleizer]

Package: bash
Version: 4.3-11+b1
Severity: important

--- Please enter the report below this line. ---

Dear Maintainer!

operating system: Debian jessie

How to reproduce?

mkdir testdir

sudo debootstrap wheezy ./testdir/ http://ftp.us.debian.org/debian/

[snipped output of debootstrap]

Consider the following ./testscript:

##

#!/bin/bash

set -x
set -e

testfunct() {
   true $0 $FUNCNAME: ok
}

export -f testfunct

type -t testfunct

bash -x -c testfunct

chroot ./testdir bash -c ls

chroot ./testdir bash -x -c env | grep -i bash_func

chroot ./testdir bash -x -c env

chroot ./testdir bash -x -c type -t testfunct

chroot ./testdir bash -x -c testfunct

##

Output:

##

user@debian:~$ sudo ./testscript
+ set -e
+ export -f testfunct
+ type -t testfunct
function
+ bash -x -c testfunct
+ testfunct
+ true 'bash testfunct: ok'
+ chroot ./testdir bash -c ls
bin  boot  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run
 sbin  selinux  srv  sys  tmp  usr  var
+ grep -i bash_func
+ chroot ./testdir bash -x -c env
+ env
BASH_FUNC_testfunct%%=() {  true $0 $FUNCNAME: ok
+ chroot ./testdir bash -x -c env
+ env
TERM=xterm
SHELL=/bin/bash
USER=root
LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arc=01;31:*.arj=01;31:*.taz=01;31:*.lha=01;31:*.lz4=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.tzo=01;31:*.t7z=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lrz=01;31:*.lz=01;31:*.lzo=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.alz=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.cab=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;
 3
5:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.m4a=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:
SUDO_USER=user
SUDO_UID=1000
USERNAME=root
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
MAIL=/var/mail/root
_=/usr/bin/env
PWD=/
LANG=de_DE.UTF-8
HOME=/root
SUDO_COMMAND=./testscript
SHLVL=2
LANGUAGE=
LOGNAME=root
BASH_FUNC_testfunct%%=() {  true $0 $FUNCNAME: ok
}
DISPLAY=:0
SUDO_GID=1000
+ chroot ./testdir bash -x -c type -t testfunct
+ type
+ chroot ./testdir bash -x -c testfunct
+ testfunct
bash: testfunct: command not found
user@debian:~$

##

Otherwise exported bash functions do work for me when having parent
scripts that export functions and child scripts that use them just fine.

The version of bash that is in Debian wheezy does not have this issue.

Cheers,
Patrick

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.16.0-4-amd64

Debian Release: 8.0
  500 testing security.debian.org
  500 testing ftp.de.debian.org

--- Package information. ---
Depends   (Version) | Installed
===-+-
base-files  (= 2.1.12) | 8
debianutils   (= 2.15) | 4.4+b1


Recommends(Version) | Installed
===-+-
bash-completion (= 20060301-0) | 1:2.1-4


Suggests  (Version) | Installed
===-+-===
bash-doc|


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#756193: --import-ownertrust

[Patrick Schleizer]

I agree, this should be fixed. It's possible. But needlessly difficult.

I don't have python code for this, but this is how gpg-bash-lib [1]
(written by me) does it. Should give you an idea how the import command
could look like.

gpg_bash_lib_internal_primary_key_fingerprint=$(gpg_bash_lib_function_key_file_to_first_primary_fingerprint
$gpg_bash_lib_internal_key)

  echo $gpg_bash_lib_internal_primary_key_fingerprint:6: | \
 gpg \
   --no-options \
   --ignore-time-conflict \
   --homedir $gpg_bash_lib_input_temp_folder \
   --import-ownertrust \
   1/dev/null \
   2/dev/null

Cheers,
Patrick

[1] https://github.com/Whonix/gpg-bash-lib


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#780970: (no subject)

[Patrick Schleizer]

Asked about this on the help-bash mailing list:
https://lists.gnu.org/archive/html/help-bash/2015-03/msg00081.html

And got a reply:
https://lists.gnu.org/archive/html/help-bash/2015-03/msg00082.html


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734794: (no subject)

[Patrick Schleizer]

Does upstream know about this issue?

What would be the real fix to solve this timing problem?

Are there commands, such as:

- 'kpartx --wait-until-ready' that waits as long as required or,

- 'kpartx --is-ready' that exits 0 or 1 accordingly.

Or would implementing those up to 'kpartx' or another project?

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#734794: (no subject)

[Patrick Schleizer]

 From: Ritesh Raj Sarraf r...@debian.org
 On 12/02/2014 07:04 PM, Sebastian Pipping wrote:
 I can confirm that kpartx needs sleep 2 /after/ adding or removing
 partitions before running some other command that assumes the
 partitions are now gone (or in place).  My guess is that something
 needs to propagate and kpartx could either wait for that change to
 happen before quitting or not, and the current code does not.

 
 When you add/remove *partitions*, yes. That's understood.

Can you please elaborate on this?

What would be the right course of action, so we don't have to hardcode
sleep 2? Is there any command that would wait until kpartx is ready?
Or that would tell us whether it's safe now or not to use kpartx?

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#788099: mat missed dependency gir1.2-gtk-3.0

[Patrick Schleizer]

Package: mat
Severity: normal

How to reproduce?

sudo apt-get install mat

sudo apt-get purge gir1.2-gtk-3.0

mat-gui

Traceback (most recent call last):
  File /usr/bin/mat-gui, line 6, in module
from gi.repository import GObject, Gtk, GLib
ImportError: cannot import name Gtk

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#758228: (no subject)

[Patrick Schleizer]

Friendly ping?


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786418: deb-systemd-helper fails to enable systemd units when using 'WantedBy = ' with spaces

[Patrick Schleizer]

Package: init-system-helpers
Version: 1.23
Severity: minor

As reported [1] on the debian-systemd mailing list, deb-systemd-helper
will not enable systemd unit files when using spaces.

The spaces in

 WantedBy = multi-user.target

are unsupported by `deb-systemd-helper`. It needs to be strictly without
spaces.

 WantedBy=multi-user.target

Martin Pitt [2]:

 Right, and that's how all other units look like too, and the manpages
don't say that extra space is allowed either (in fact it is explicitly
not between e. g. '!' or '|' and the program name).

 So, please feel free to file a minor bug against deb-systemd-helper,
but I wouldn't recommend shipping units like that.

Cheers,
Patrick

[1]
https://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2015-May/007273.html

[2]
https://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2015-May/007273.html


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786421: warn against usage of spaces, i.e. 'Type = notify' in systemd unit files

[Patrick Schleizer]

Package: lintian
Severity: wishlist

systemd man pages always uses the syntax without spaces, for example
'Type=notify' and so forth.

A systemd contributor on #systemd irc.freenode.net also recommended
against it.

zdzichu adrelanos: please do not use spaces
zdzichu adrelanos: there was recently a problem with spaces in ExecStart=

There is an issue with deb-systemd-helper when using spaces. [1]

Therefore I suggest to add a lintian warning when spaces of that type
are found in systemd unit files.

Cheers,
Patrick

[1] deb-systemd-helper fails to enable systemd units when using
'WantedBy = ' with spaces [2]
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786418


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#786418: (no subject)

[Patrick Schleizer]

related lintian feature request...

warn against usage of spaces, i.e. 'Type = notify' in systemd unit files

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=786421

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#796235: rinetd fills up the logs until disk is full up if it cannot bind

[Patrick Schleizer]

Package: rinetd
Version: 0.62-5.1
Severity: critical
X-Debbugs-CC: t...@punkave.com
X-Debbugs-CC: whonix-de...@whonix.org

When rinetd cannot bind, it quickly fills up the logs. Confirmations.
[1] [2]

CC'd upstream, Tom Boutell.

Tom, do you still maintain rinetd?

Severity critical chosen, because it fills up the disk very quickly.
Then nothing else works anymore.

Cheers,
Patrick

[1] http://i-admin.blogspot.de/2005/06/jun-8-145750-rinetd21939-accept0.html
[2] https://bugs.launchpad.net/ubuntu/+source/rinetd/+bug/568094

Bug#794099: optional non-zero exit codes in case of restart(s) required

[Patrick Schleizer]

Package: needrestart
Severity: wishlist

When running 'needrestart' from a terminal or script, it would be useful
to have some command line parameter to make it exit non-zero, in case
any restart(s) are required.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#764007: (no subject)

[Patrick Schleizer]

What's the status of this?

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#795519: debhelper: dh_installinit should run systemd-tmpfiles if a /usr/lib/tmpfiles.d/ snippet gets shipped for systemd-only packages also

[Patrick Schleizer]

Package: debhelper
Severity: normal
Usertags: pkg-systemd-maintainers tmpfiles.d

As explained verbosely on the pkg-systemd-maintainers mailing list [1],
when a package ships a /usr/lib/tmpfiles.d/ snippet while at the same
time that package does not ship a sysvinit script, then the
'systemd-tmpfiles --create' debhelper auto generated code [2] is missing.

Cheers,
Patrick

[1]
http://lists.alioth.debian.org/pipermail/pkg-systemd-maintainers/2015-August/008483.html
[2]
# Automatically added by dh_installinit
# In case this system is running systemd, we need to ensure that all
# necessary tmpfiles (if any) are created before starting.
if [ -d /run/systemd/system ] ; then
systemd-tmpfiles --create /usr/lib/tmpfiles.d/pkg-name.conf /dev/null
|| true
fi
# End automatically added section

Bug#793416: help making systemd drop-in overwrite files take effect

[Patrick Schleizer]

Felipe Sateler:
 On 23 July 2015 at 17:28, Patrick Schleizer adrela...@riseup.net wrote:
 Package: dh-systemd
 Severity: wishlist

 Could you please add a feature, so debhelper (dh-systemd) could help
 making systemd drop-in overwrite files
 (/lib/systemd/system/unit.service.d/override.conf) take effect?

 (systemctl daemon-reload + service restart)

 (guarded by [ -d /run/systemd/system ])

 (Override files shipped by different packages.)
 
 I'm not sure a package should restart anothe service. Is there
 precedent for this? I seem to recall libc or libssl asking me which
 services I should restart, but I don't remember ever seeing any
 packages restart other services.

I am not aware of any examples within Debian. My use case are user
specific packages, where you deploy a configuration package. We make use
of this in Debian derivatives, Whonix [a derivative of Debian] and Qubes
[Debian templates].

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793376: su-to-root: higher priority for kdesudo and gksudo

[Patrick Schleizer]

Bill Allombert:
 On Thu, Jul 23, 2015 at 12:46:25PM +, Patrick Schleizer wrote:
 Package: menu
 Severity: wishlist

 Dear maintainer!

 Please consider the following patch.

 It improves SU_TO_ROOT_X auto detection code. It prefers kdesudo
 (because it's more modern, supports /etc/sudoers.d etc.) and gksudo over
 gksu.
 
 Hello Patrick,
 
 Not all Debian systems are set up to allow users to use sudo.
 As far as I understand, kdesudo only work on such system,
 thus it cannot be prefered to kdesu.
 
 Cheers,
 

Even if not disallowed. Even without any custom sudoers settings, this
patch would work? No disadvantages by it?

kdesudo works on any system. sudo apt-get install kdesudo, that's it.
No special settings required. And if one would not have it installed,
su-to-root would act as it does now. No difference then.

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793376: su-to-root: higher priority for kdesudo and gksudo

[Patrick Schleizer]

Bill Allombert:
 On Thu, Jul 23, 2015 at 10:42:59PM +, Patrick Schleizer wrote:
 Bill Allombert:
 On Thu, Jul 23, 2015 at 12:46:25PM +, Patrick Schleizer wrote:
 Package: menu
 Severity: wishlist

 Dear maintainer!

 Please consider the following patch.

 It improves SU_TO_ROOT_X auto detection code. It prefers kdesudo
 (because it's more modern, supports /etc/sudoers.d etc.) and gksudo over
 gksu.

 Hello Patrick,

 Not all Debian systems are set up to allow users to use sudo.
 As far as I understand, kdesudo only work on such system,
 thus it cannot be prefered to kdesu.

 Cheers,


 Even if not disallowed. Even without any custom sudoers settings, this
 patch would work? No disadvantages by it?

 kdesudo works on any system. sudo apt-get install kdesudo, that's it.
 No special settings required. And if one would not have it installed,
 su-to-root would act as it does now. No difference then.
 
 I just tested kdesudo and gksudo and they certainly do not work if the user is
 not allowed to use sudo, but is allowed to use su.
 
 Are you seeing something different ?
 
 Cheers,
 Bill.

You're right!

Covering that case in the updated patch.

Commit:
https://github.com/adrelanos/menu/commit/6626a5c6e7364c8cd26ae20dfb04962743fe9fbe

Branch:
https://github.com/adrelanos/menu/tree/kdesudo_gksudo_2

Pull request:
https://github.com/adrelanos/menu/pull/2

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793376: su-to-root: higher priority for kdesudo and gksudo

[Patrick Schleizer]

Package: menu
Severity: wishlist

Dear maintainer!

Please consider the following patch.

It improves SU_TO_ROOT_X auto detection code. It prefers kdesudo
(because it's more modern, supports /etc/sudoers.d etc.) and gksudo over
gksu.

commit:
https://github.com/adrelanos/menu/commit/cfbaf0bc5b4dc497f827e4677c46c050b0ec0a4e

branch:
https://github.com/adrelanos/menu/tree/kdesudo_gksudo

pull request:
https://github.com/adrelanos/menu/pull/1

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793416: help making systemd drop-in overwrite files take effect

[Patrick Schleizer]

Package: dh-systemd
Severity: wishlist

Could you please add a feature, so debhelper (dh-systemd) could help
making systemd drop-in overwrite files
(/lib/systemd/system/unit.service.d/override.conf) take effect?

(systemctl daemon-reload + service restart)

(guarded by [ -d /run/systemd/system ])

(Override files shipped by different packages.)

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#793376: su-to-root: higher priority for kdesudo and gksudo

[Patrick Schleizer]

Bill Allombert:
 On Thu, Jul 23, 2015 at 11:57:04PM +, Patrick Schleizer wrote:
 Even if not disallowed. Even without any custom sudoers settings, this
 patch would work? No disadvantages by it?

 kdesudo works on any system. sudo apt-get install kdesudo, that's it.
 No special settings required. And if one would not have it installed,
 su-to-root would act as it does now. No difference then.

 I just tested kdesudo and gksudo and they certainly do not work if the user 
 is
 not allowed to use sudo, but is allowed to use su.

 Are you seeing something different ?

 You're right!

 Covering that case in the updated patch.
 
 So your patch is doing
 if sudo -n true /dev/null 21 ; then
 
 The sudo documentation says:
  -n, --non-interactive
  Avoid prompting the user for input of any kind.  If a 
 password is required
  for the command to run, sudo will display an error message 
 and exit.
 
 so it does not work because sudo ask for a password the first time: I get
 
 %sudo -n true
 sudo: sorry, a password is required to run sudo

But it does not block? It's non-interactive? If yes, then that's
supposed to be that way. It's used as test to figure out whether the
user is allowed to use sudo [and by extension, kdesudo] or not.

In that case - in case the user is not allowed to use sudo - then sudo
would exit non-zero. The new code block that would prefer kdesudo/gksudo
would be skipped. The usual detection code would take over.

Cheers,
Patrick


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#822693:

[Patrick Schleizer]

The user amending PATH is not great as this would be ignored by
(background) applications running other applications.

For example update-flashplugin-nonfree run by postinst would use
/usr/bin/gpg rather than /use/local/bin/gpg because it will not have the
same PATH setting as the user. Etc.

> Though it would behave differently than expected when the tool is not
installed (launching firejail instead of erroring with "No such file ...").

The wrappers could just be minimal scripts that would redirect to the
main wrapper. And the main wrapper could would emulate acting as
expected if the tool is not installed.

firejail + binary installed:
-> start firejailed binary

firejail + binary not installed:
-> not use firejail and just act as if there was no wrapper. Example
/usr/local/bin/gpg would do...
exec /usr/bin/gpg "$@"

uwt ( https://github.com/Whonix/uwt ) wrappers act like this.
(Additionally, it is handling command-not-found.)

I am not sure that is a perfect solution yet. It would not cover
stackable wrappers. I.e. I would not know yet how to automatically add
torsocks (uwt) as well as firejail at the same time. Perhaps a generic
stackable wrapper mechanism is required? Perhaps this is a bigger,
general discussion for debian-devel?

Bug#820111: document how to use per-user systemd --user services

[Patrick Schleizer]

Package: systemd
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

please document how to use per-user systemd --user services.

- how to do that for a login console
- how to do that for an X session

(If there is any difference.)

Steps I done:

sudo apt-get install libpam-systemd dbus

sudo loginctl enable-linger user

Drop the service in /etc/systemd/user/mytest.service.

systemctl --user enable mytest

'ps aux | grep systemd' shows that 'systemd --user' is running.

Manual 'systemctl --user start mytest' works for me. But it is never
automatically started.

After reboot, 'systemctl --user status mytest' always shows loaded,
enabled, inactive, dead.

I might be doing something wrong. Please consider documenting how to do
that.

Cheers,
Patrick

Bug#819824: easy mode for needrestart

[Patrick Schleizer]

Package: needrestart
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

we are wondering if needrestart should be installed by default in Whonix.

When needrestart is automatically run during apt-get dist-upgrade,
I am concerned, that its output by default is too technical and verbose
and will therefore add more confusion.

Therefore I am hereby kindly asking if you could add an easy mode please?

- can be enabled by dropping some file into /etc/needrestart/conf.d
- no automatic restart
- it's output would be limited to the following

> Services need to be restarted. Reboot recommended.
> For more information, see 'man needrestart'.

Or does the current configuration already allow configuring needrestart
that way?

Cheers,
Patrick

Bug#824290: add dpkg trigger for /usr/share/netfilter-persistent/plugins.d folder to have newly installed plugins take effect

[Patrick Schleizer]

Package: netfilter-persistent
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

please add a dpkg trigger. Once a plugin is dropped into
/usr/share/netfilter-persistent/plugins.d folder, the service
netfilter-persistent should be restarted so the new plugins will take
effect.

Cheers,
Patrick

Bug#675008: (no subject)

[Patrick Schleizer]

Christoph Anton Mitterer:
> So if you think that a working solution, which is used by others,
isn't the correct one... what is you suggestion how to do it? ;-)

I am a afraid, I believe he already answered that above.

> So the best thing would be to bring such a proposal to the LSB, or to
FreeDesktop, and then implement that one after it is accepted.

Would you be up to do that?

Cheers,
Patrick

Bug#675008: LSB feature request

[Patrick Schleizer]

Patrick Schleizer:
> Posted an LSB feature request:
> 
> define bash non-login shell snippet drop-in folder /etc/bash.bashrc.d/
> in LSB
> 
> https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=4167

Mats Wichmann:
> This won't happen: LSB says nothing about bash, rather it requires
only a POSIX shell.

> Reserving a directory for bash usage would fall more in the domain of FHS.

Therefore, posted a FHS feature request:

'define bash non-login shell snippet drop-in folder /etc/bash.bashrc.d/
in FHS' [2]

Cheers,
Patrick

[1] https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=4167#c2
[2] https://bugs.linuxfoundation.org/show_bug.cgi?id=1367

Bug#832802: usage of network-pre.target results in systemd ordering cycle

[Patrick Schleizer]

Package: netfilter-persistent
Severity: grave
X-Debbugs-CC: whonix-de...@whonix.org
Tags: security

Dear maintainer,

I am using the following minimal systemd unit file for testing purposes.

###
/lib/systemd/system/my-test.service

[Unit]
Description=my-test-firewall-service

Before=network-pre.target
Wants=network-pre.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true
StandardOutput=syslog

[Install]
WantedBy=multi-user.target
###

Enabled it using "sudo systemctl enable my-test.service". It results in
a systemd ordering cycle.

Jul 29 01:23:59 localhost systemd[1]: Found ordering cycle on
basic.target/start
Jul 29 01:23:59 localhost systemd[1]: Found dependency on
sysinit.target/start
Jul 29 01:23:59 localhost systemd[1]: Found dependency on
networking.service/start
Jul 29 01:23:59 localhost systemd[1]: Found dependency on
network-pre.target/start
Jul 29 01:23:59 localhost systemd[1]: Found dependency on
my-test.service/start
Jul 29 01:23:59 localhost systemd[1]: Found dependency on basic.target/start
Jul 29 01:23:59 localhost systemd[1]: Breaking ordering cycle by
deleting job networking.service/start
Jul 29 01:23:59 localhost systemd[1]: Job networking.service/start
deleted to break ordering cycle starting with basic.target/start

Alternatively I tried "WantedBy=network-pre.target", but that resulted
in the systemd unit not being automatically activated after boot at all.
It stays in a loaded, enabled, inactive status. (Manual systemctl start
my-test worked.)

I think this is security relevant since to learn that there is a systemd
ordering cycle one has to look at the syslog. And systemd's automatic
breaking of the chain might result in the firewall not being load early
enough?

Cheers,
Patrick

Bug#675008: bash should source package hooks into interractive shells

[Patrick Schleizer]

I don't think this LSB / FHS approach is appropriate here. I appreciate
having got a very reasonable response from LSB / FHS.

> https://bugs.linuxfoundation.org/show_bug.cgi?id=1367
> 
> --- Comment #1 from Jeff Licquia  ---

> In general, LSB and FHS don't mind if someone like Debian wants to
> implement something like this.  We particularly don't want to be the
> "gatekeepers of innovation" in any way.  So if you're asking for our
> blessing to do this, you have it.

> [...]

> First, are other distros on board with something like this?  Or do
> they already support such a thing?
>
> [...]

Matthias Klose:
> So the best thing would be to bring such a proposal to the LSB, or to
> FreeDesktop, and then implement that one after it is accepted.

Matthias, having quoted the above, I do not think this is how it works.
LSB / FHS are not, and do not want to be the gatekeepers of innovation.
As I understand, they neither desire, expect nor encourage innovations
such as this to go through them. Rather, Debian and/or Fedora etc.
innovate something and it may be standardized then.

[And as a personal remark, I am glad it is that way, that there is no
bureaucratic authority above Debian that hinders innovation.]

So in conclusion, please do no let this LSB / FHS approach block this
ticket.

Bug#832911: broken systemd dependencies may result in firewall not being load early enough

[Patrick Schleizer]

Package: firewalld
Severity: grave
X-Debbugs-CC: whonix-de...@whonix.org
Tags: security

Dear maintainer,

the systemd dependencies in firewalld.service are broken. It leads to a
systemd ordering cycle. And systemd's automatic breaking of the chain
might result in the firewall not being load early enough.

References:

- https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832802
- https://lists.freedesktop.org/archives/systemd-devel/2016-July/037236.html
- https://lists.freedesktop.org/archives/systemd-devel/2016-July/037242.html

Related:

- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829640
- http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829752

Cheers,
Patrick

Bug#834196: add dpkg trigger for /etc/audit/rules.d folder to have newly installed rules files take effect

[Patrick Schleizer]

Package: auditd
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

please add a dpkg trigger. Once a new auditd rules file is dropped into
/etc/audit/rules.d folder, run within the Debian maintainer script:

/sbin/augenrules --load || true

Cheers,
Patrick

Bug#675008: LSB feature request

[Patrick Schleizer]

Posted an LSB feature request:

define bash non-login shell snippet drop-in folder /etc/bash.bashrc.d/
in LSB

https://lsbbugs.linuxfoundation.org/show_bug.cgi?id=4167

Cheers,
Patrick

Bug#829740: (no subject)

[Patrick Schleizer]

Sorry, I did not get e-mail notifications so I missed your replies here
and answer late.

My Debian packaging questions (copyright lintian warning and combined
man page) have been sorted out after asking on Debian mentors mailing list.

I have forked and successfully packaged corridor for Debian. [1] There
are no lintian --pedantic warnings. One additional, rather simple [also
litian --pedantic warning free] dependency, genmkfile. [2]

The package has been uploaded to Whonix's deb repository and is
currently being tested. [3]

u:
> I'm not sure how useful this is exactly.

corridor can be used to check systems / programs that should cause only
Tor traffic really do. corridor can log any clearnet, non-Tor traffic.

Ideally, corridor gets installed on a physically isolated device running
Debian with two network adapters. Let's call that corridor-Gateway. Then
start Tails, TBB or Whonix behind such a corridor-Gateway. Should there
be any accidental clearnet traffic (leaks), then corridor could log it
and would block it.

Alternatively, corridor can be installed in a Debian based VM. Another
VM could run Tails, TBB or Whonix-Gateway. These VMs would be configured
to connect through corridor-Gateway.

Perhaps I am not the greatest corridor evangelist. Does that make more
sense now?

> It's still beta?

corridor by rustybird is perhaps not beta anymore? Quote:

"Not such a terribly early release anymore" [4]

I have opened a ticket to inquiry about the release status. [5]

Cheers,
Patrick

[1] https://github.com/adrelanos/corridor
[2] https://github.com/adrelanos/genmkfile
[3] https://www.whonix.org/wiki/Corridor
[4]
https://github.com/rustybird/corridor/commit/4390c2a3f8ff34983cb18074f1865a33f5255af0
[5] https://github.com/rustybird/corridor/issues/25

Bug#776152: provide meaningful exit codes for network failures

[Patrick Schleizer]

Julian Andres Klode:
> On Sat, Jan 24, 2015 at 04:50:04PM +0000, Patrick Schleizer wrote:
>> Package: apt
>> Severity: important
>>
>> When "apt-get update" fails the program exits with a 0 status.
>> It would be useful if it exited with a non-zero status in that case
>> (or if there were a switch to tell it to do so).
> 
> I disagree that it should do that. We just redefined successful update
> (for the success hook) to mean "not all sources failed". In case we
> fetch anything, that's still a success, as we update the cache with
> the new data.

Then perhaps have a new command line parameter? Such as 'apt-get
--strict update' or 'apt-get strict-update' or something like that?

Cheers,
Patrick

Bug#829640: netfilter-persistent loads firewall rules too late

[Patrick Schleizer]

Package: netfilter-persistent
Severity: grave
X-Debbugs-CC: whonix-de...@whonix.org
Tags: security

Dear maintainer,

there is a security issue with the netfilter-persistent systemd service. [1]

netfilter-persistent orders itself before the wrong target. Should be
'Before=network-pre.target'.

The systemd manual is quite clear on network.target and
network-pre.target. [2]

Credits for finding this bug go to rustybird. [3] [4] (I am only
seconding and reporting it.)

(Using severity grave as this could pose a security risk, i.e. the
firewall getting up too late.)

Cheers,
Patrick

[1]
https://anonscm.debian.org/cgit/collab-maint/iptables-persistent.git/tree/systemd/netfilter-persistent.service
[2] https://www.freedesktop.org/software/systemd/man/systemd.special.html
[3] https://github.com/rustybird
[4] https://github.com/rustybird/corridor/issues/8#issuecomment-230266161

Bug#829752: netfilter-persistent systemd service does not lock the network if netfilter-persistent wrapper is failing at system bootup

[Patrick Schleizer]

Package: netfilter-persistent
Severity: grave
X-Debbugs-CC: whonix-de...@whonix.org
Tags: security

Dear maintainer,

there is a security issue with the netfilter-persistent systemd service. [1]

If the netfilter-persistent wrapper [2] fails for some reason, it does
not load any firewall rules and does not lock the network.

For example `whoami` or `run-parts` could be corrupted on disk or
otherwise broken. Or one of the firewall scripts in
/usr/share/netfilter-persistent/plugins.d folder could be broken.

If the netfilter-persistent wrapper fails on system startup, it should
lock the network. I.e. set all iptables and ip6tables policies to drop.

Cheers,
Patrick


Credits for finding this bug go to rustybird. [3] [4] (I am only
seconding and reporting it.)

(Using severity grave as this could pose a security risk, i.e. the
firewall getting up too late.)

[1]
https://anonscm.debian.org/cgit/collab-maint/iptables-persistent.git/tree/systemd/netfilter-persistent.service
[2]
https://anonscm.debian.org/cgit/collab-maint/iptables-persistent.git/tree/netfilter-persistent
[3] https://github.com/rustybird
[4] https://github.com/rustybird/corridor/issues/8#issuecomment-230266161

Bug#829640: Acknowledgement (netfilter-persistent loads firewall rules too late)

[Patrick Schleizer]

Rusty Bird:
> They also have to add Wants=network-pre.target then,
> https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

Bug#829740: [Pkg-privacy-maintainers] Bug#829740: RFP: corridor - a Tor traffic whitelisting gateway

[Patrick Schleizer]

Hi!

Is someone from the PkgPrivacyMaintainers team interested / willing to
help get corridor [4] [5] [6] into Debian?

I got a working prototype of a Debian package which is almost free of
lintian warnings. [1] [2] [3] There are just some remaining --pedantic
lintian warnings that are fixable. First questions...

1)

I: corridor source: unused-file-paragraph-in-dep5-copyright paragraph at
line 3

https://github.com/adrelanos/corridor/blob/debian_new/debian/copyright

Any idea what is wrong in the debian/copyright file?

2)

Would a combined manpage, i.e. 'man corridor', symlinked to the
individual command names (corridor-init-forwarding, corridor-init-snat,
...) be acceptable by Debian policy and otherwise or should a separate
man page per binary be provided?

Cheers,
Patrick


(Sorry for breaking the thread and re-posting this. I was signed up to
Pkg-anonymity-tools, but not yet to pkg-privacy-maintainers. I thought
by replying to the RFP bug, my reply would get cc'd here which it did
not. And I never figured out how to manually figure out a mailing list
reference number and replicate it so that the thread does not break.)

[1] https://github.com/rustybird/corridor/issues/10
[2] https://github.com/adrelanos/corridor/tree/debian_new
[3]
hhtts://github.com/rustybird/corridor/compare/master...adrelanos:debian_new?expand=1

[4] https://github.com/rustybird/corridor
[5]
http://lists.alioth.debian.org/pipermail/pkg-privacy-maintainers/Week-of-Mon-20160704/000814.html
[6] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829740

Bug#829740: RFP: corridor - a Tor traffic whitelisting gateway

[Patrick Schleizer]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-privacy-maintain...@lists.alioth.debian.org

* Package name: corridor
  Version : 20160705124628
  Upstream Author : rustybird 
* URL : https://github.com/rustybird/corridor
* License : ISC / public domain
  Programming Lang: shell
  Description : a Tor traffic whitelisting gateway

long description:

There are several transparently torifying gateways. They suffer from the
same problems:

- It's tricky to isolate circuits and issue NEWNYM signals, especially
if multiple client computers are involved.
- Any garbage software can pump identifiers into "anonymous" circuits,
and get itself exploited by malicious exit nodes.
- Trust is centralized to the gateway, which is bad enough when used by
ne person, and just inappropriate when shared with strangers.

corridor takes a different approach. It allows only connections to Tor
relays to pass through (no clearnet leaks!), but client computers are
themselves responsible for torifying their own traffic. In other words,
it is a filtering gateway, not a proxying gateway.

You can think of it as defense in depth for your vanilla Tor Browser or
Tails, for your beautiful scary experimental Qubes proxying schemes,
etc. Or invite the hood to use your WiFi without getting into trouble.

license file:

https://github.com/rustybird/corridor/blob/master/LICENSE

Bug#829740: Acknowledgement (RFP: corridor - a Tor traffic whitelisting gateway)

[Patrick Schleizer]

Hi!

Is someone from the PkgPrivacyMaintainers team interested / willing to
help get corridor into Debian?

I got a working prototype of a Debian package which is almost free of
lintian warnings. [1] [2] [3] There are just some remaining --pedantic
lintian warnings that are fixable. First questions...

1)

I: corridor source: unused-file-paragraph-in-dep5-copyright paragraph at
line 3

https://github.com/adrelanos/corridor/blob/debian_new/debian/copyright

Any idea what is wrong in the debian/copyright file?

2)

Would a combined manpage, i.e. 'man corridor', symlinked to the
individual command names (corridor-init-forwarding, corridor-init-snat,
...) be acceptable by Debian policy and otherwise or should a separate
man page per binary be provided?

Cheers,
Patrick

[1] https://github.com/rustybird/corridor/issues/10
[2] https://github.com/adrelanos/corridor/tree/debian_new
[3]
hhtts://github.com/rustybird/corridor/compare/master...adrelanos:debian_new?expand=1

Bug#833474: please use configuration folder /etc/audit/rules.d/ by default

[Patrick Schleizer]

Package: auditd
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

/lib/systemd/system/auditd.service it is currently using [relevant snippet]:

#
[Service]
ExecStart=/sbin/auditd -n
## To use augenrules, copy this file to /etc/systemd/system/auditd.service
## and uncomment the next line and delete/comment out the auditctl line.
## Then copy existing rules to /etc/audit/rules.d/
## Not doing this last step can cause loss of existing rules
#ExecStartPost=-/sbin/augenrules --load
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
#

Could /etc/audit/rules.d/ be processed by default?

The following should work:

#
[Service]
ExecStartPre=-/sbin/augenrules --load
ExecStart=/sbin/auditd -n
ExecStartPost=-/sbin/auditctl -R /etc/audit/audit.rules
#

Cheers,
Patrick

Bug#820111: Info received (document how to use per-user systemd --user services)

[Patrick Schleizer]

By Debian stretch default, there are some default systemd user unit
files in `/usr/lib/systemd/user/`.

With a different path on Debian stretch
`/usr/lib/systemd/user/mytest.service`:

```
[Unit]
Description=mytest

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true

[Install]
WantedBy=default.target
```

systemctl --user enable mytest

Worked for me.

> `Created symlink
/home/user/.config/systemd/user/default.target.wants/mytest.service →
/usr/lib/systemd/user/mytest.service.`

After reboot, mytest.service will be active.

Bug#829752: do not bring up the network if the firewall fails

[Patrick Schleizer]

A way to fix this would be to not bring up the network if the firewall
fails. I suggest adding the following file:

/lib/systemd/system/networking.service.d/30_netfilter-persistent.conf

With the following content:

[Unit]
## Fail Closed Mechanism.
## When the firewall systemd service failed, do not bring up the network.
Requires=netfilter-persistent.service

Bug#829640: netfilter-persistent.service suggestion

[Patrick Schleizer]

Thank you for working on this patch!

Me and rustybird agreed on the following. Please consider using the
following as netfilter-persistent.service.

#

[Unit]
Description=netfilter persistent configuration
DefaultDependencies=no

Wants=network-pre.target
Before=network-pre.target

Wants=systemd-modules-load.service local-fs.target
After=systemd-modules-load.service local-fs.target

Conflicts=shutdown.target
Before=shutdown.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/sbin/netfilter-persistent start
ExecStop=/usr/sbin/netfilter-persistent stop

[Install]
WantedBy=multi-user.target

#

When using DefaultDependencies=no and Conflicts=shutdown.target, one
should also use Before=shutdown.target. [1]

When using Wants=network-pre.target, one should also use
Before=network-pre.target. [2]

Cheers,
Patrick

[1]
https://www.freedesktop.org/software/systemd/man/systemd.special.html#shutdown.target
[2] https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

Bug#856217: [/lib/systemd/system/user@.service:13] Invalid user/group name or numeric ID, ignoring: .service

[Patrick Schleizer]

Package: systemd
Severity: normal
X-Debbugs-CC: whonix-de...@whonix.org

sudo service user@.service status
● user@.service.service - User Manager for UID .service
   Loaded: loaded (/lib/systemd/system/user@.service; static; vendor
preset: enabled)
   Active: inactive (dead)

Feb 26 17:15:17 user systemd[1]: [/lib/systemd/system/user@.service:13]
Invalid user/group name or numeric ID, ignoring: .service

Debian stretch. systemd 232-15

Bug#856217: [/lib/systemd/system/user@.service:13] Invalid user/group name or numeric ID, ignoring: .service

[Patrick Schleizer]

Do you think this warning could / should be removed?

Bug#829640: (no subject)

[Patrick Schleizer]

> 1) It's still al just Wants, no Requires... i.e. if netfilter rules
loading fails for whichever reason, the boot process will continue just
normally, with networking and any daemons, that possibly require
netfilter for their security, being brought up.

There is a separate bug report for this:

'netfilter-persistent systemd service does not lock the network if
netfilter-persistent wrapper is failing at system bootup'

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829752

I guess let's please use that one.

> 2) Some daemons might actually improperly start even before
network.target or network-pre.target... while this is certainly bad, it
likely happens in the realworld... so a dependency (or at least a Wants)
on something much earlier would be useful... e.g. sysinit.target, which
I use for that.

Not sure about that. Not sure we should add workarounds here to fix
grave bugs in other packages.

Do you have an real world examples?

And even if daemons start before network-pre.target, it should be save,
since network is not up at that point? And by the time network is up,
the firewall will be up earlier.

Please consider creating a new bug report if you still think that is an
issue.

> 3) I don't quite understand the benefit of:
> Conflicts=shutdown.target
> Before=shutdown.target

Understandably. The benefits are minor.

- It is the correct thing to do as per systemd documentation.
- It will result in a more correct (and perhaps slightly faster)
shutdown. The service gets terminated just as any other service. No
systemd auto cleanup for still running services after shutdown.target
code paths will be needed.

> Doesn't this actually open a possible window int which daemons may
still run but netfilter-persistent is going to be stopped and thus rules
might be removed?

No, because the systemd service will be stopped using "service
netfilter-persistent stop" - which by default does nothing, does not
remove and iptables rules. It does not run "service netfilter-persistent
flush".

You can verify this by making your firewall plugins verbose. (In case of
bash, xtrace, 'set -x'.) Then shutdown and watch your syslog /
journalctl of your last shutdown.

It might be an issue for users using netfilter-persistent configration
option FLUSH_ON_STOP, but I have no idea who on earth would enable this
anyhow. Perhaps that option should be removed, but that is worth another
bug report.

Thank you for also thinking all of this through, more eyes are certainly
helpful!

Cheers,
Patrick

Bug#845496: /var/log/syslog spam host brltty[204]: file system mount error: usbfs[brltty-usbfs] -> /var/run/brltty/usbfs: No such device

[Patrick Schleizer]

Package: brltty
Severity: normal
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

brltty keeps spamming /var/log/syslog.

host brltty[204]: file system mount error: usbfs[brltty-usbfs] ->
/var/run/brltty/usbfs: No such device

Like 20 messages every 2 minutes or so.

Running on Debian jessie (Whonix) inside a VirtualBox VM.

Cheers,
Patrick

Bug#845922: virtualbox-guest-x11 broken after jessie to stretch upgrade

[Patrick Schleizer]

Package: virtualbox-guest-x11
Severity: important
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

after upgrading from jessie to stretch inside VirtualBox (Whonix), X is
no longer starting.

Even though the old kernel module was uninstalled and the new one
installed by dkms during upgrade.

no suitable module for running kernel

After "sudo apt-get purge virtualbox-guest-utils" and "sudo apt-get
install virtualbox-guest-x11" everything is back to normal.

Cheers,
Patrick

Bug#848279: deprecate InRelease in favor of Release.gpg

[Patrick Schleizer]

Package: apt
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

In light of CVE-2016-1252...

When there is Release.gpg implemented in apt, why not deprecate InRelease?

Bug#824939: (no subject)

[Patrick Schleizer]

I can confirm this.

Without kwin installed, there are no window title bars, which makes it
pretty unusable.

Best regards,
Patrick

Bug#851175: plasma-workspace - All shell packages missing. This is an installation issue, please contact your distribution - missing dependency on plasma-desktop-data

[Patrick Schleizer]

Package: plasma-workspace
Severity: grave
X-Debbugs-CC: whonix-de...@whonix.org

Installing plasma-workspace alone on Debian stretch (after a jessie ->
stretch upgrade) leads to leads to the KDE desktop being totally
unusable only showing the following error popup.

All shell packages missing. This is an installation issue, please
contact your distribution

As per http://stackoverflow.com/a/39765593/2605155 installing
plasma-desktop-data solved this very issue. Therefore
plasma-desktop-data included it is a missing dependency of
plasma-workspace. Please add.

Best regards,
Patrick

Bug#850474: RFP: ZeroNet - Decentralized websites using Bitcoin crypto and BitTorrent network

[Patrick Schleizer]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-privacy-maintain...@lists.alioth.debian.org

* Package name: zeronet
  Version : v0.5.0
  Upstream Author : HelloZeroNet
* URL : https://zeronet.io
* License : GPL-2
  Programming Lang: python
  Description : Decentralized websites using Bitcoin crypto and
BitTorrent network

long description:

Open, free and uncensorable websites, using Bitcoin cryptography and
BitTorrent network

license file:

https://github.com/HelloZeroNet/ZeroNet/blob/master/LICENSE

deb packaging:

https://github.com/HelloZeroNet/ZeroNet/issues/241

https://github.com/bashrc/zeronet-debian

Bug#820111: document how to use per-user systemd --user services

[Patrick Schleizer]

Michael Biebl:
> Can you attache the full output of
> systemctl status --user mytest
> 
> and the completer mytest.service unit.

You looking into this is appreciated!

cat /etc/systemd/user/mytest.service
[Unit]
Description=mytest

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/true

[Install]
WantedBy=multi-user.target

systemctl status --user mytest
● mytest.service - mytest
   Loaded: loaded (/etc/systemd/user/mytest.service; enabled)
   Active: inactive (dead)

Best regards,
Patrick

Bug#754242: (no subject)

[Patrick Schleizer]

Is this actually implemented despite saying wontfix?

Acquire::BlockDotOnion "false";

allows connecting to http://asdfasdf.onion without tor://

Thank you for implementing 'Acquire::BlockDotOnion "false";' - very
useful for Whonix!

Best regards,
Patrick

Bug#859121: RFP: genmkfile - Generic Makefile

[Patrick Schleizer]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-privacy-maintain...@lists.alioth.debian.org

* Package name: genmkfile
  Version : 4.0
  Upstream Author : Patrick Schleizer <adrela...@riseup.net>
* URL : https://github.com/Whonix/genmkfile
* License : GPL-3+
  Programming Lang: bash and make
  Description : Generic Makefile

long description:

Makes packaging scripts simpler. No more need to manually maintain 'make
install' targets or distribution specific install files such as
debian/pkg-name.install.

Files in etc/... in root source folder will be installed to /etc/...,
files in usr/... will be installed to /usr/... and so forth. This should
make renaming, moving files around, packaging, etc. very simple.
Packaging of most packages can look very similar.

Provides common make targets such as 'make install'. Very extensible
through file ./make-helper-overrides.bsh or folder
./make-helper-overrides.d. By using overrides, any make target can be
easily extended using pre or post hooks or replaced.

Contains a minimal Makefile while the heavy lifting is done by a bash
script make-helper.bsh.

use case:

onion-grater would be a great addition to Debian because it would
improve usability for users that use applications using Tor's ControlPort.

onion-grater is a Tor ControlPort filter written by anonym (Tails
project) that has been packaged by Patrick Schleizer (Whonix project).
The packaged version of onion-grater depends on genmkfile.

stability:

The genmkfile package has been used by the Whonix project for years to
package more than 100 deb packages.

packaging effort:

Hopefully very little. The /debian folder has already been implemented
and long term tested. The package is lintian --pedantic clean. Since the
package is rather simple, no compiled code, just scripts, it should be
already reproducible. Ideally, a Debian Developer could easily build it
and upload to Debian. Please tell me if any changes are required to make
it fit for inclusion into Debian.

license file:

https://github.com/Whonix/genmkfile/blob/master/debian/copyright

building:

Should be as simple as three commands. apt-get installing the build and
runtime dependencies, creating an upstream tarball and then create a deb
package.

make dist

sudo apt-get --yes --no-install-recommends install debhelper devscripts
strip-nondeterminism fakeroot perl make dpkg-dev sudo perl

dpkg-buildpackage

Cheers,
Patrick
(genmkfile upstream author)

Bug#859125: RFP: onion-grater - Whitelisting Tor Control Protocol Filter

[Patrick Schleizer]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: pkg-privacy-maintain...@lists.alioth.debian.org

* Package name: onion-grater
  Version : 3.0
  Upstream Author : anonym (Tails project)
* URL : https://github.com/Whonix/onion-grater
* License : GPL-3+
  Programming Lang: python3
  Description : Whitelisting Tor Control Protocol Filter

long description:

Filters out Tor control protocol commands that are dangerous for
anonymity such as GETINFO ADDRESS using a whitelist. Acts as a proxy
between the client application and Tor.

use case:

onion-grater would be a great addition to Debian because it would
improve usability and security for users that use applications using
Tor's ControlPort.

onion-grater is a Tor ControlPort filter written by anonym (Tails
project) that has been packaged by Patrick Schleizer (Whonix project).
The packaged version of onion-grater depends on genmkfile.

At the moment users of applications such as onionshare and ricochet that
use Tor ephemeral hidden services will not work out of the box. This is
because, rightly so, user accounts to not have write access to Tor's
ControlSocket file /var/run/tor/control for security reasons.

Users have to add themselves to the debian-tor group by using "sudo
adduser user debian-tor" which is a usability issue (command line
required for otherwise easy to use applications) as well as a security
issue since then they have full unfiltered Tor ControlPort access from
their user account. (Unfiltered Tor ControlPort allows running commands
such as 'GETINFO address' which reveals one's real external IP address,
which is bad in case of application compromise since that is counter to
what users of Tor want.)

To work around this issue, onionshare started to depend on
torbrowser-launcher, because torbrowser-launcher would install the Tor
Browser Bundle and require that running since that would provide Tor
ControlPort access without having the user to add oneself to the
debian-tor group.

Once onion-grater was in Debian, onionshare could depend on
onion-grater. onion-grater could provide a unix domain socket file that
is readable and writeable by any application. onion-grater would enforce
proper filtered access. Then onionshare could ship a onion-grater
profile and use onion-grater.

This would improve usability, since the user would no longer have to add
oneself to the debian-tor group. onionshare and other applications would
work out of the box with no configuration required. It would also
improve security, since a compromised user account would only have
limited access to Tor's available control protocol commands.

If I understood this right, this approach found consensus among anonym
and intrigeri (Tails project), Micah Lee (onionshare) and me (Patrick
Schleizer, Whonix project).

onion-grater would also be installed by default in the derivatives of
Debian, Tails and Whonix.

packaging effort:

Hopefully very little. The /debian folder has already been implemented
and tested in Whonix (a derivative of Debian). The package is lintian
--pedantic clean. Since the package is rather simple, no compiled code,
just scripts, it should be already reproducible. Ideally, a Debian
Developer could easily build it and upload to Debian. Please tell me if
any changes are required to make it fit for inclusion into Debian.

license file:

https://github.com/Whonix/onion-grater/blob/master/debian/copyright

dependencies:

Just one dependency that is not in Debian yet. genmkfile [1]. But
hopefully easy to get into Debian?

building:

Should be as simple as three commands. apt-get installing the build and
runtime dependencies, creating an upstream tarball and then creating a
deb package.

sudo apt-get --yes --no-install-recommends install debhelper genmkfile
dh-systemd dh-apparmor adduser tor python3 python3-psutil python3-stem
python3-yaml python3-sdnotify

make dist

dpkg-buildpackage

Cheers,
Patrick

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859121

Bug#859121: [Pkg-privacy-maintainers] Bug#859121: RFP: genmkfile - Generic Makefile

[Patrick Schleizer]

related:

[1]

RFP: onion-grater - Whitelisting Tor Control Protocol Filter

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859125


Hi Antoine!

Antoine Beaupré:
> Funny you send this issue to the maintainers' mailing list..

It was my impression pkg-privacy-maintain...@lists.alioth.debian.org
would be the appropriate place where interested people might read,
please correct me if I am wrong.

> I would have prefered to see a RFP regarding that onion-grater software,
> which I can't find anywhere using a search engine... URL? :)

A separate RFP was created just now. [1] Thought it would be the right
approach to have one per package.

Thanks,
Patrick

Bug#860721: please enable Tor2webMode compile time option

[Patrick Schleizer]

Package: tor
Severity: whishlist
X-Debbugs-CC: whonix-de...@whonix.org

Dear Maintainer,

please enable Tor2webMode compile time option.

# How?

Please add to debian/control dh_auto_configure

--enable-tor2web-mode

And in src/or/config.c change from

V(Tor2webMode, BOOL, "0"),

to

V(Tor2webMode, BOOL, "1"),

(Should that src/or/config.c change be moved upstream?)

That would allow one to use torrc option "Tor2webMode 1".

# Why?

This is useful on client machines in combination if the server is using
HiddenServiceSingleHopMode 1
HiddenServiceNonAnonymousMode 1

Then one can get secure, fast, free onion hostname, lan network
configuration independent, NAT traversal incoming ports. Very handy for
sys admins.

Otherwise compiling Tor oneself is rather time consuming. (Research and
typing all the commands, perhaps repeating all of that.)

# Security

"HiddenServiceSingleHopMode 1" and "HiddenServiceNonAnonymousMode 1" are
insecure options wrt anonymity, and these can be set by default. These
have clear descriptions in Tor manual that these are non-anonymous and
there is no way to accidentally set these options as these are not
mentioned in default /etc/tor/torrc.

Therefore please consider making "Tor2webMode 1" equally easy to use.

Cheers,
Patrick

Bug#856587: fake-tty shared object or command line tool

[Patrick Schleizer]

Package: moreutils
Severity: whishlist
X-Debbugs-CC: whonix-de...@whonix.org

feature request:

fake-tty [application] - fools application into detecting being run
inside a tty

I am not a C coder, but at least a shared object looks easy to implement.

echo "int isatty(int fd) { return 1; }" | gcc -O2 -fpic -shared -ldl -o
"fake-tty.so" -xc -

usage:

LD_PRELOAD+=" fake-tty.so"

LD_PRELOAD="$LD_PRELOAD" apt-get "$@" 2>&1 | tee -a "$logfile"

(Preserves colors and download speed in terminal output that would
otherwise be eaten by using the pipe.)

use case:

1)
http://stackoverflow.com/questions/1401002/trick-an-application-into-thinking-its-stdin-is-interactive-not-a-pipe/26263980#26263980

python -c 'import pty, sys; pty.spawn(sys.argv[1:])' \
   | apt-get "$@" 2>&1 \
   | tee -a "$logfile"

2)
http://unix.stackexchange.com/questions/347970/how-to-create-a-real-copy-of-file-descriptor-stdout-and-stderr-without-using-unb

non-alternatives:

- script(1) man page says "It is not recommended to run script in
non-interactive shells.".

- unbuffer(1) does not correctly return the exit code if the process is
killed. Has a dependency on tcl.

Could you ship such fake-tty command line tool or shared object for
LD_PRELOAD with moreutils please?

Best regards,
Patrick

Bug#866187: add torrc.d configuration directory

[Patrick Schleizer]

Peter Palfrader:
> I'm tempted to stop shipping upstream's torrc as /etc/tor/torrc.  It's
> full of options that most users should never set, and shipping an almost
> empty one is much nicer.
> 
> I suspect that approximately the only thing it ought to have is the
> include line.

I was too afraid to suggest such as drastic change, but I like the idea
very much.

Bug#866187: add torrc.d configuration directory

[Patrick Schleizer]

Peter Palfrader:
> I don't think having torrc sourced in the defaults is a good approach.

What's wrong with that?

I guess because then users cannot easily disable parsing of /etc/torrc.d?

Bug#910017: Apparmor profile whitelist /etc/torrc.d/ and /usr/local/etc/torrc.d/

[Patrick Schleizer]

Any chance to get any entry by default pointing to something in
/usr/local such as

/usr/local/etc/tor/** r,

or so?

That would be very useful for Qubes, and Qubes-Whonix (since /usr/local
is persistent by default in TemplateBased AppVMs while /etc is not).

Even if Debian wouldn't parse any Tor config in /usr/local by default (I
wouldn't suggest it), having '/usr/local/etc/torrc.d/** r,' or so by
default would help a lot.

Wouldn't be any disadvantage for Debian (except for a single unused
apparmor line) and simpler for Qubes since extending an apparmor profile
as a distribution is unclean. (config-package-dev displace
/etc/apparmor.d/local/system_tor but not pretty.)

Bug#910017: Apparmor profile whitelist /etc/torrc.d/ and /usr/local/etc/torrc.d/

[Patrick Schleizer]

Peter Palfrader:
> On Mon, 01 Oct 2018, Patrick Schleizer wrote:
> 
>> Package: tor
>> Severity: normal
>> X-Debbugs-CC: whonix-de...@whonix.org
>>
>>> [warn] Could not open "/etc/torrc.d/40_tor_control_panel.conf":
>> Permission denied
>>
>> Please allow in apparmor profile by default:
>>
>> /etc/torrc.d/ r,
>> /usr/local/etc/torrc.d/ r,
> 
> Is tor using these directories by default?

Not yet.

> 
> If so, that should be fixed.  If not, then these aren't the right
> directories for .d things anyhow.

Which ones are?

Bug#910017: Apparmor profile whitelist /etc/torrc.d/ and /usr/local/etc/torrc.d/

[Patrick Schleizer]

Package: tor
Severity: normal
X-Debbugs-CC: whonix-de...@whonix.org

> [warn] Could not open "/etc/torrc.d/40_tor_control_panel.conf":
Permission denied

Please allow in apparmor profile by default:

/etc/torrc.d/ r,
/usr/local/etc/torrc.d/ r,

Bug#909816: dependency issues - enigmail : Depends: thunderbird (>= 1:52.0) but it is not going to be installed or

[Patrick Schleizer]

Package: enigmail
Severity: grave
X-Debbugs-CC: whonix-de...@whonix.org

Happening on Debian stretch.

sudo apt-get install enigmail
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 enigmail : Depends: thunderbird (>= 1:52.0) but it is not going to be
installed or
 icedove (>= 1:52.0)
E: Unable to correct problems, you have held broken packages.

Bug#909746: Request for provision of Debian v3 onions for source repositories

[Patrick Schleizer]

Package: tor
Severity: whishlist
X-Debbugs-CC: whonix-de...@whonix.org

Dear System Administrators,

Recent Tor alpha releases by The Tor Project are beginning to make v3
onions the default for newly created onion services.

  https://blog.torproject.org/new-release-tor-0351-alpha

> **Changes in version 0.3.5.1-alpha - 2018-09-18**

> Major features (onion services, UI change):

> For a newly created onion service, the default version is now 3. Tor
still supports existing version 2 services, but the operator now needs
to set "HiddenServiceVersion 2" in order to create a new version 2
service. For existing services, Tor now learns the version by reading
the key file. Closes ticket 27215.

In the near future, v3 onions will become ubiquitous. v3 onions provide
significant security and anonymity benefits over v2 onions. Could you
please consider implementing this option? It would also further cement
Debian's reputation as a forward-looking, security-focused GNU/Linux
distribution.

Perhaps marking it as an "experimental" feature at first? v3 load
balancing is not available, but hopefully soon.

Thank you for your consideration.

Bug#926116: cross build failing - update-binfmts: warning: qemu-i386 not in database of installed binary formats.

[Patrick Schleizer]

No more issues since I upgraded to buster.

mmdebstrap is awesome! Thank you!

Cheers,
Patrick

Bug#926116: cross build failing - update-binfmts: warning: qemu-i386 not in database of installed binary formats.

[Patrick Schleizer]

Package: mmdebstrap
Severity: normal
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

# How to reproduce:

sudo /home/user/whonix_dot/Whonix/help-steps/mmdebstrap --verbose
--architectures=i386 stretch /var/cache/pbuilder/base.cow_i386
/home/user/whonix_dot/Whonix/build_sources/debian_stable_current_clearnet.list

(Could probably simplified but I hope you can reproduce this easily /
hope you also have usr/bin/mkdir.)

# Expected result:

No error.

# Actual result:

> I: automatically chosen mode: root
> I: i386 cannot be executed, falling back to qemu-user
> update-binfmts: warning: qemu-i386 not in database of installed binary 
> formats.
> update-binfmts: exiting due to previous errors
> qemu-i386 is not a supported binfmt name at 
> /home/user/whonix_dot/Whonix/help-steps/mmdebstrap line 1838.

# Misc:

/usr/sbin/update-binfmts --display qemu-i386

> update-binfmts: warning: qemu-i386 not in database of installed binary 
> formats.
> update-binfmts: exiting due to previous errors

I guess the issue is somewhere here:

open my $fh, '-|', '/usr/sbin/update-binfmts', '--display',
"qemu-$options->{qemu}" // die "failed to fork(): $!";
chomp (my $binfmts = do { local $/; <$fh> });
close $fh;
if ($binfmts eq '') {
die "qemu-$options->{qemu} is not a supported binfmt 
name";
}

Removing
die "qemu-$options->{qemu} is not a supported binfmt name";
helps as a workaround. I can now build i386 on amd64.

Building armhf or arm64 fails.

I: installing packages...
/usr/sbin/chroot: failed to run command ‘dpkg’: Permission denied
env --unset=APT_CONFIG /usr/sbin/chroot
/var/cache/pbuilder/base.cow_arm64 dpkg --install --force-depends
/var/cache/apt/archives//sysvinit-utils_2.88dsf-59.9_arm64.deb ...
/home/user/whonix_dot/Whonix/help-steps/mmdebstrap line 551.

This might be more a user support question than actual bug. I hope you
don't mind me asking here. Please kindly let me know if I should take
this elsewhere please.

> dpkg -l | grep qemu
> ii  ipxe-qemu 
> 1.0.0+git-20161027.b991c67-1   all  PXE boot firmware - 
> ROM images for qemu
> ii  qemu  1:2.8+dfsg-6+deb9u5 
>amd64fast processor emulator
> ii  qemu-slof 20161019+dfsg-1 
>all  Slimline Open Firmware -- QEMU PowerPC version
> ii  qemu-system   1:2.8+dfsg-6+deb9u5 
>amd64QEMU full system emulation binaries
> ii  qemu-system-arm   1:2.8+dfsg-6+deb9u5 
>amd64QEMU full system emulation binaries (arm)
> ii  qemu-system-common1:2.8+dfsg-6+deb9u5 
>amd64QEMU full system emulation binaries (common files)
> ii  qemu-system-mips  1:2.8+dfsg-6+deb9u5 
>amd64QEMU full system emulation binaries (mips)
> ii  qemu-system-misc  1:2.8+dfsg-6+deb9u5 
>amd64QEMU full system emulation binaries 
> (miscellaneous)
> ii  qemu-system-ppc   1:2.8+dfsg-6+deb9u5 
>amd64QEMU full system emulation binaries (ppc)
> ii  qemu-system-sparc 1:2.8+dfsg-6+deb9u5 
>amd64QEMU full system emulation binaries (sparc)
> ii  qemu-system-x86   1:2.8+dfsg-6+deb9u5 
>amd64QEMU full system emulation binaries (x86)
> ii  qemu-user 1:2.8+dfsg-6+deb9u5 
>amd64QEMU user mode emulation binaries
> ii  qemu-user-static  1:2.8+dfsg-6+deb9u5 
>amd64QEMU user mode emulation binaries (static version)
> ii  qemu-utils1:2.8+dfsg-6+deb9u5 
>amd64QEMU utilitie

I am using mmdebstrap (git version) and I am still on Debian stretch.
Perhaps stretch is unsupported and all of this works in buster?

Kind regards,
Patrick

Bug#921163: coreutils such as /bin/mkdir are duplicated in /usr/bin/mkdir

[Patrick Schleizer]

Package: mmdebstrap
Severity: normal
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

# How to reproduce:

sudo mmdebstrap --mode=root
--aptopt=/home/user/whonix_binary/aptgetopt.conf stretch
/var/cache/pbuilder/base.cow
/home/user/whonix_dot/Whonix/build_sources/debian_stable_current_clearnet.list

(Could probably simplified but I hope you can reproduce this easily /
hope you also have usr/bin/mkdir.)

# Expected result:

base.cow/bin/mkdir exists.

base.cow/usr/bin/mkdir does not exist

# Actual result:

base.cow/bin/mkdir exists.

base.cow/usr/bin/mkdir exists.

base.cow/usr/bin/mkdir matches base.cow/bin/mkdir.

diff base.cow/usr/bin/mkdir base.cow/bin/mkdir ; echo $?
0

Also many (if not all) other coreutils that should only reside in /bin
such as /bin/rm are duplicated in /usr/bin such as /usr/bin/rm.

# Why this is a problem:

/usr/bin is preferred over /bin with default $PATH setting.

- When coreutils is later updated, it will only update /bin/mkdir and so
forth but not /usr/bin/mkdir. This is because /bin/mkdir is owned by
coreutils (dpkg -S /bin/mkdir) but /usr/bin/mkdir is owned by no package
(dpkg -S /usr/bin/mkdir).

- This leads to apparmor issues. In apparmor profiles one has to
hardcode for example /bin/mkdir but since /usr/bin/mkdir exists, this
call will be denied.

# Misc:

I couldn't figure out from the source code why this is happening.
Intended or unintended behavior? If intended, can this be turned off?
Are also other files in unusual places?

Kind regards,
Patrick

Bug#927972: jitterentropy_rng.ko never loads

[Patrick Schleizer]

On https://www.whonix.org/pipermail/whonix-devel/2019-April/001371.html
its developer wrote:

> [...]
> - the in-kernel crypto API has an RNG framework that provides a DRBG.
This
DRBG is used for in-kernel crypto API purposes. It may be accessed from
user
space via AF_ALG [2]. Yet, this is not accessible from /dev/random, /dev/
urandom or getrandom. The DRBG uses the in-kernel JitterRNG to seed itself.
> [...]

Better entropy for in-kernel crypto API purposes sounds good as a
general security enhancement.

Fedora enables this kernel module by default, too.

Does this sound like a good idea to enable loading this kernel module by
default in Debian?

Bug#927974: jitterentropy_rng.ko never loads: jitternentropy-rngd doesn't complain

[Patrick Schleizer]

Luca Boccassi:
> As far as I know, the kernel module and the userspace daemon are
> separate and independent, and serve different purposes.
> 

It's developer wrote about it here:

https://www.whonix.org/pipermail/whonix-devel/2019-April/001371.html

Bug#928546: [feature request] /etc/fstab.d

[Patrick Schleizer]

Asked upstream about it.

[feature request] /etc/fstab.d

https://github.com/karelzak/util-linux/issues/790

Bug#928546: replies by upstream util-linux and systemd

[Patrick Schleizer]

util-linux Karel Zak @karelzak replied:

https://github.com/karelzak/util-linux/issues/790

> The libmount allows to read fstab stuff from directory, for example
>
> ```
>  mount --fstab /etc/fstab.d/
> ```
>
> but this feature is not enabled by default and it does not check for
fstab.d/ by default. (see "man mount" for more details).
>
> The problem is that /etc/fstab is de-facto standard and on many places
(in linux ecosystem) we do not expect this feature. The nice example is
libc getmntent() API, another important is consumer systemd,
/sbin/mount. helpers, many 3rd party scripts etc ... so it's not about
util-linux.
>
> This is reason why libmount does not support it natively (although I
agree that /etc/fstab.d/ itself is a good idea).


systemd Lennart Poettering @poettering replied:

https://github.com/systemd/systemd/issues/12506#issuecomment-490227369

> We don't define the /etc/fstab format, util-linux does that and we
noawadays use util-linux' apis to parse it. Hence if you want soething
like that, you'd have to work with the util-linux folks, and then ths
would magically just work in systemd.
>
> That said, if I were you I'd just write a generator that looks at
/etc/fstab and creates drop-ins for the .mount units
systemd-fstab-generator generates that override the Option= line. i.e.
let systemd-fstab-generator do its thing as it currently does (meaning:
translating fstab into native systemd .mount unit files), but then have
your own generator that tweak some of these mount units with additional
generated drop-ins as you need.
>
> Anyway, let's close this, as I don't think we should change this in
systemd upstream. I hope that makes sense.

Bug#931994: improve key strengthening, add rounds=65536 to /etc/pam.d/common-password

[Patrick Schleizer]

Package: libpam-runtime
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

could you please append 'rounds=65536' to 'password [success=1
default=ignore] pam_unix.so obscure sha512' in file
/usr/share/pam/common-password ? In other words:

/usr/share/pam/common-password currently has:

password[success=1 default=ignore]  pam_unix.so obscure sha512

Could that be made

password[success=1 default=ignore]  pam_unix.so obscure sha512 
rounds=65536

please?

rationale: improve key strengthening

quote https://wiki.archlinux.org/index.php/SHA_password_hashes :

> The rounds=N option helps to improve key strengthening. The number of
rounds has a larger impact on security than the selection of a hash
function. For example, rounds=65536 means that an attacker has to
compute 65536 hashes for each password he tests against the hash in your
/etc/shadow. Therefore the attacker will be delayed by a factor of
65536. This also means that your computer must compute 65536 hashes
every time you log in, but even on slow computers that takes less than 1
second. If you do not use the rounds option, then glibc will default to
5000 rounds for SHA-512. Additionally, the default value for the rounds
option can be found in sha512-crypt.c.

Kind regards,
Patrick

Bug#927290: CoyIM in buster freeze up

[Patrick Schleizer]

Package: coyim
Severity: normal
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

CoyIM freezes during account creation in Debian buster.

More details were already submitted upstream but this might be a Debian
only bug.

https://github.com/coyim/coyim/issues/527

Kind regards,
Patrick

Bug#934751: RFP: linux-hardened - hardened Linux kernel

[Patrick Schleizer]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-ker...@lists.debian.org

* Package name: linux-hardened
  Version : 5.2
  Upstream Author : linux-hardened
* URL : https://github.com/anthraxx/linux-hardened
* License : GPL-2
  Programming Lang: C
  Description : Minimal supplement to upstream Kernel Self
Protection Project changes. Features already provided by SELinux + Yama
and archs other than multiarch arm64 / x86_64 aren't in scope. Only tags
have stable history. Shared IRC channel with KSPP: irc.freenode.net
##linux-hardened

Maybe as an alternative, not replacement for the usual Debian linux kernel.

Bug#934820: consider review and merge of linux-hardened patches (free, Libre alternative to grsecurity)

[Patrick Schleizer]

Package: linux
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

Could you please consider review and merge of linux-hardened patches
(free, Libre alternative to grsecurity).

https://github.com/anthraxx/linux-hardened

Alternatively perhaps as a separate package.

RFP: linux-hardened - hardened Linux kernel

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934751

Kind regards,
Patrick

Bug#934457: installation in chroot failing with Unknown device "/dev/fuse": No such device

[Patrick Schleizer]

Package: fuse
Severity: grave
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

The following code from /var/lib/dpkg/info/fuse.postinst is failing.

if [ -e /dev/fuse ]
then
 udevadm test --action -p  $(udevadm info -q path -n /dev/fuse)
> /dev/null 2>&1
fi


+ [ -e /dev/fuse ]
+ udevadm info -q path -n /dev/fuse
Unknown device "/dev/fuse": No such device

Happening inside a Debian buster chroot.

Kind regards,
Patrick

Bug#934457: installation in chroot failing with Unknown device "/dev/fuse": No such device

[Patrick Schleizer]

Thank you very much for looking into this!

Does the following information help to make head or tail of this?
Otherwise, I will provide better instruction for reproduction.

László Böszörményi (GCS):
>  How did you create that Buster chroot?


#!/bin/bash

set -x
set -e

img=/home/user/test.img

export http_proxy="http://127.0.0.1:3142;

export DEBUG="true"
export KERNEL="linux-image-amd64"

sudo -E \
bash -x \
grml-debootstrap \
--arch amd64 \
--filesystem ext4 \
--force \
--hostname host \
--mirror http://ftp.us.debian.org/debian \
--keep_src_list \
--password changeme \
--release buster \
--verbose \
--vmfile \
--vmsize "2G" \
--target "$img"


> Mine was created with
> 'pbuilder create' and


I guess it has to do with which folders are mounted in the chroot.

> I do have the fuse device in the chroot.

I have.

ls -la /dev/fuse
crw-rw-rw- 1 0 0 10, 229 Aug 29 07:10 /dev/fuse


fuse installation,

- works with only /dev mounted in chroot
- works with only /proc mounted in chroot
- does not work with both, /dev and /proc mounted in chroot


It is mounted using:

mount --bind "/dev" "$CHROOT_FOLDER/dev"
mount --bind "/proc" "$CHROOT_FOLDER/proc"

> As noted above, if the fuse device is not there, the udevadm is not
> run due to the check for that being false. One thing came into my mind
> is that you have the chroot on a mount point that has the nodev
> option. Can you check that please?


By the time this bug happened, nodev was not in use.

(Maybe nodev will be used in the future if that is possible.)


Setting up fuse (2.9.9-1) ...
+ set -e
+ [ -c /dev/cuse ]
+ chrooted
+ stat -c %d/%i /
+ stat -Lc %d/%i /proc/1/root
+ [ 64768/2 = 51715/2 ]
+ return 0
+ dpkg-statoverride --list /bin/fusermount
+ chmod 4755 /bin/fusermount
+ modprobe fuse
+ true
+ [ -x /sbin/lsmod ]
+ lsmod
+ grep -qs fuse
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/loop/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/xt_conntrack/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/nft_counter/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/nft_chain_nat_ipv4/holders': No such file or
directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/ipt_MASQUERADE/holders': No such file or
directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/nf_nat_ipv4/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/nf_nat/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/nf_conntrack/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/nf_defrag_ipv6/holders': No such file or
directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/nf_defrag_ipv4/holders': No such file or
directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/libcrc32c/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/nft_compat/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/nf_tables/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/nfnetlink/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/fuse/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/binfmt_misc/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/intel_rapl/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/crct10dif_pclmul/holders': No such file or
directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/crc32_pclmul/holders': No such file or directory
libkmod: ERROR ../libkmod/libkmod-module.c:1931 kmod_module_get_holders:
could not open '/sys/module/crc32c_intel/holders': No such file or directory
libkmod: ERROR 

Bug#939188: grub-PC check_signatures=enforce support (non-EFI)

[Patrick Schleizer]

Package: grub2
Severity: wishlist
X-Debbugs-CC: whonix-de...@whonix.org

Could you please make it possible to do signature verification with
grub-pc too?

Rationale:

We, the maintainers of Linux distributions that primarily run inside VMs
(Whonix; Kicksecure) would like to implement verified boot. Not
necessarily Secure Boot.

At the moment, there are no tools that can create VM images (with Debian
Linux) which support EFI booting. Also, support by virtualizers such as
KVM, Xen, VirtualBox for Secure Boot is either non-existing or undocumented.

Another reason is, that inside VMs we don’t necessarily need the
complexity of EFI.

Instead we could boot unverified (usual virtual BIOS legacy boot) from a
virtual, read-only (write protected) boot medium (such as ISO). That
boot loader on the initial boot disk (grub2) could then verify and
chainload the boot loader (grub2) on the main disk. Which then would go
on to verify the kernel. In result, we would have a verified boot sequence.

Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

[Patrick Schleizer]

Package: mmdebstrap
Severity: normal
X-Debbugs-CC: whonix-de...@whonix.org

Dear maintainer,

could you please make mmdebstrap compatible with grml-debootstrap,
pbuilder and cowbuilder?

These applications support setting a custom debootstrap but mmdebstrap
cannot yet serve as a drop-in replacement for debootstrap since its
command line interface is different.

Dunno if becoming a debootstrap drop-in replacement is one of your
goals. In case it is, just reporting the incomparability.

At the moment I am wrenching a custom wrapper in between which is not great.

https://github.com/Whonix/Whonix/blob/master/help-steps/pbuilder-debootstrap-command-filter

That wrapper might also give clues what kind of incompatibilities were
found.

Kind regards,
Patrick

Bug#940188: compatibility with grml-debootstrap, pbuilder and cowbuilder

[Patrick Schleizer]

Awesome! Great to know you're interested in this!

Good question. I am not sure what I meant with that either. :) Will look
into it again.

First thing:



debootstrap:

--arch=ARCH

mmdebstrap:

--architectures=native[,foreign1,...]



In other words, grml-debootstrap calls debootstrap with --arch=ARCH.
This will fail since mmdebstrap does not support --arch=ARCH but wants
--architectures.



cowbuilder (or pbuilder?) calls debootstrap with:

+ args='--include=apt --variant=buildd --force-check-gpg buster
/var/cache/pbuilder/base.cow_amd64 http://HTTPS///deb.debian.org/debian'

I.e. it is possible to pass an apt repository URI through command line
(above last argument).

However, I am translating that in the wrapper to:

--verbose --architectures=amd64
--aptopt=/home/user/whonix_binary/aptgetopt.conf
--include=apt,sudo,devscripts,debhelper,strip-nondeterminism,fakeroot,apt-transport-tor,apt-transport-https,python,eatmydata,aptitude,cowdancer
buster /var/cache/pbuilder/base.cow_amd64
/home/user/Whonix/build_sources/debian_stable_current_clearnet.list

Using a file
/home/user/Whonix/build_sources/debian_stable_current_clearnet.list
which contains both, Debian "standard" repository as well as Debian
security repository.

This is to make use of mmdebstrap excellent security feature to
bootstrap from two repositories at once. If the APT version in Debian
"standard" repository had a vulnerability, then the vulnerable version
would be installed first before vulnerable APT would be used to upgrade
in a later step from Debian security repository.

"Incompatibility" is perhaps a far stretched term. How do we "teach"
grml-debootstrap, cowbuilder (or pbuilder?) "use both, Debian "standard"
repository and Debian security repository when using mmdebstrap"?

It's like "the ecosystem does not take advantage of mmdebstrap" yet.

Not sure anymore why I added:
--include=apt,sudo,devscripts,debhelper,strip-nondeterminism,fakeroot,apt-transport-tor,apt-transport-https,python,eatmydata,aptitude,cowdancer

apt-transport-https might be required to support https repositories in
sources list.

apt-transport-tor might be required to support tor+https and .onion in
sources list.

Johannes Schauer:

> I added a no-op --force-check-gpg option.

Where is the source code for that? git clones just now.

git clone http://gitlab.mister-muffin.de/josch/mmdebstrap.git

But cannot find any mention of "force-check-gpg".

Once I have the new version, and can get past the "force-check-gpg"
option, I will re-try these tools and see how far I get step by step.

Cheers,
Patrick