Port to Linux

[andreasjunestam]

yontma should be ported to Linux

[kfogel]

Would love to see this ported to Linux (and eventually become part of the default kernel, so any user can configure it, presumably via their desktop's System->Settings menu).

[adrelanos]

I am interested as well.

[schoen]

Tom Ritter said that it would be helpful to mention here how to get the power and Ethernet events.

The command-line tools acpi_listen and mii-tool -w will let you get these states (acpi_listen as a subscribe/notify matter, mii-tool -w as a matter of polling). I don't know if there's a way to subscribe to mii status without polling (which could consume a little bit of CPU unnecessarily).

[schoen]

A better solution for mii status (which unfortunately does still poll, but probably has very low resource utilization) is mii-diag --monitor. It outputs "a single line per link change" where the first word is "down", "up", "negotiating", or "unknown".

[ioerror]

I'd imagine that dbus will also give the alerts that most people expect for each of these events.

[schoen]

If you depend on acpid, you can also put your own scripts in /etc/acpi/events that will be automatically run by acpid in respond to power events.

[schoen]

Yeah, dbus would also have events for these. It might make it totally desktop-environment-specific, unfortunately.

You can see screensaver activation and deactivation events on interface=org.gnome.ScreenSaver,member=ActiveChanged and power plug status changes on interface=org.gnome.SettingsDaemon.Power,member=Changed.

NetworkManager sends (somewhat belated) dbus notifications about interfaces that go down to org.freedesktop.Notifications, but I'm not sure that's ideal because they're not sent until NetworkManager has actually finished taking the network interface down, which seemed to be five or more seconds after the cable was unplugged, whereas mii-diag seems to give them more promptly. I didn't see any other dbus notifications directly about unplugging the cable (and the interface could conceivably also go down for a reason other than loss of link, like if a DHCP lease expired without being renewed).

[ioerror]

It seems that such a daemon should listen for dbus events as well as others. systemd for example includes some anti-forensics checks such as locking the screen when it detects specific usb devices like the Mouse Jiggler.

So, perhaps the daemon should start a boot and take stock of the (usb, pci) device tree, look for specific changes from dbus, mii-diag, and other programs or interfaces. If the screen is locked, we could do something like hibernate or perhaps panic in another way.

It should be rather easy to write this in a privilege separated manner - it does seem that systemd is the ideal place if we were to add it to existing software but not all systems use systemd.

[virtadpt]

It would also be possible to splice this into the existing laptop-mode structure of scripts so that it is run whenever a "mains power is disconnected" ACPI event gets logged.

[ioerror]

There a few different events that I care about:

• Movement by from accelerometer
• Ethernet cable disconnects
• Wifi disconnects (and stays down)
• Power disconnected
• Total or high packet loss (in the case of a vampire tap/loop back)
• Custom tests that when they fail, we know the network has died ( eg: fetch over Tor )
• Low battery
• New USB devices
• New PCI devices
• New cardbus devices
• New monitors

Depending on which event and the current state of the machine, I'd want to hibernate, hard halt or simply lock the screen.

[micahflee]

Just adding my +1. I'm also interested in a port to Linux.

[catskillmarina]

I love this idea. Maybe make this like a reactive firewall aganst unknown devices too. If you want a device to be allowed, you add it explicitly. If an unknown device is added, the machine hibernates. A secure wipe of memory a-la tails would be nice.

[andreasjunestam]

Looking for volunteers! :)

[DrWhax]

Interested in this as well.

[abeluck]

another +1

[schoen]

Is it worthwhile to make a shell script that implements this basic functionality with acpi_listen and mii-diag, even though it's not particularly elaborate or elegant?

I think I've gotten a lot of the way there with

#!/bin/bash

if [ $(id -u) -ne 0 ]
then
echo "This program should be run as root. For example:"
echo
echo "sudo $0"
exit 1
fi

{ acpi_listen & sudo mii-diag -w; } 2>/dev/null | awk '/(no link|^ac.*0$)/ {print "yontma!", $0; system("/usr/sbin/pm-suspend");}'

[schoen]

Er, pm-hibernate. :-) pm-suspend has a cold boot attack vulnerability.

[schoen]

This seems to work properly, at least if you run it as root or as a user with sudo access and you have acpi_listen, mii-diag, and pm-hibernate available.

It could be set to run when the machine boots (rc.local or the like), and then it would affect the system as a whole, independent of the currently logged-in user.

#!/bin/bash

if [ $(id -u) -ne 0 ]
then

This program should be run as root.

if [ -z "$DISPLAY" ]
then
exec sudo $0 $*
else
exec gksudo $0 $*
fi
fi

{ acpi_listen & sudo mii-diag -w; } 2>/dev/null | awk '/(no link|^ac.*0$)/ {print "yontma!", $0; system("/usr/sbin/pm-hibernate");}'

[micah]

I like this idea and the implementation seems simple enough.

However, what seems to be missing in this discussion is that there are situations where you do not want any of these events to happen and there needs to be a a simple way to indicate such.

I dont know about you, but I move my laptop from one room to the other by unplugging my power and I often have power events that would trigger a suspend at unfortunate times. There are other suggestions in that bug like triggering on USB events, or packetloss. I would not be so happy if I plug in my USB headset to take a sip call only to have my machine suspend on me. A packetloss trigger would effectively make my train trip be really amusing.

One of the oft quoted critiques of security is that usability suffers. Let us try to inject some usability into this discussion. There are people I know who use FDE who would not use this if they have to open a terminal and find the process that is running and kill it every time they want to move to the couch (not to mention restart it).

One simple modification might be to make it so it only activates when xscreensaver triggers. For example, xscreensaver can be configured to blank and lock after one minute of inactivity so if you ever neglect to do that when you walk away, it will do it for you as quick as possible. Perhaps that is all that is needed here is to integrate this into a screen lock?

[kfogel]

Amen to what Micah said. Schoen's script is a start (maybe even a core implementation) of the back-end functionality. But the real problem is in making this useable and minimizing the convenience/security tradeoff. Integrating it as a screensaver option seems like the most natural way to go...

[schoen]

Hi folks,

I was just trying to replicate what I understood to be the functionality of the Windows version (unconditionally hibernating on either of these two events). My version here doesn't have any error-checking or configurability, and I'm not sure that a standalone shell script is even the right approach.

In terms of ioerror's suggestions, I'm not sure what considerations a user should use to decide on the conditions under which they want to hibernate; in terms of micah's concerns, I'm not sure how one would best communicate to the system that it doesn't have to hibernate during a particular change or movement event (without allowing someone else who takes the computer away from doing the same action to prevent the hibernation).

It might make sense to try to think this through with some users who think they would actually want to use Linux yontma on a regular basis and try to specify a more complex behavior.