Douane personal firewall for GNU/Linux

>The sg command works similar to newgrp but accepts a command. The command will be executed with the /bin/sh shell. With most shells you may run sg from, you need to enclose multi-word commands in quotes. Another difference between newgrp and sg is that some shells treat newgrp specially, replacing themselves with a new instance of a shell that newgrp creates. This doesn't happen with sg, so upon exit from a sg command you are returned to your previous group ID.

I could not find sg(1) for FreeBSD, neither in base nor in ports, but FreeBSD does have newgrp(1) mentioned above. The FreeBSD manpage for newgrp(1) notes:

>For security reasons, the newgrp utility is normally installed without the setuid bit. To enable it, run the following command:

> chmod u+s /usr/bin/newgrp

The main source file of newgrp(1), /usr/src/usr.bin/newgrp/newgrp.c is 310 lines long so I think creating an sg(1) based on that one and maybe also by looking at doas(1) -- which is in ports, not in base -- should not be too difficult.

However, I think using sg(1) to protect against random malicious binaries and shell scripts having internet access equates roughly to security by obscurity in that it only protects you as long as the malicious code is unaware of sg(1).

Consider the following (which I wrote without testing it with a group limiting firewall but it should work like this):

  nw_access_group=
  while IFS= read -r curr_group ; do
    nw_access_group="$curr_group"
    sg "$nw_access_group" 'curl -s http://www.example.com/' >/dev/null
    if [[ $? -eq 0 ]] ; then
      break
    fi
  done <<EOF
  $( getent group | grep "$USER" | cut -d':' -f1 )
  EOF

  echo "Would use group $nw_access_group for evil stuff."

How? When the zero day hits, the program has long been marked as trusted and the firewall will just happily let it go along. Besides, even if you're an experienced user and the firewall is smart enough to figure out that the application is talking to a server that it's never talked before (which isn't even sustainable for a lot of applications), it's very likely that you'll see the alert way before you read the news about the zero-day, and you'll just shrug and allow it to continue because you trust that program.

(Edit: maybe personal firewalls got smarter since I last used one and there's something else I'm missing here?)

> Maybe macOS apps are different, but I never had this experience during while using little snitch for almost 10 years.

The kind of applications that actively snoop on users as a business model -- the ones that you want to block in the first place -- sometimes even do this deliberately (which is something that I know from experience, not something that I suspect). Inexperienced users quickly figure out it's the firewall that gives them trouble, and they'll pick disabling the firewall over not playing with their toy any time. This works for pretty much any sort of permissions.

For example, last time I ran it on my tablet, Instagram's application was crippled to uselessness because I had disabled camera access (my girlfriend only needed to post a photo on an account that she managed): as soon as it opened, it spit out a big fat error message saying it can't access the camera and that you should allow camera access if you want to be able to take photos. As soon as you tapped ok, the same error popped up, and the application never loaded.

macOS apps aren't any different, you're just running the right ones :-).