1. 30
  1.  

  2. 3

    doing what weston-launch did, but in a saner way

    weston-launch is already pretty sane :) Shameless plug: I Rewrote It In Rust (well, not protocol compatible with the original weston-launch, just the same idea.) My version uses Capsicum sandboxing on FreeBSD. The (privileged) parent has a socket to the child, a kqueue and a descriptor to /dev, that’s it. No way to open ~/.ssh/secret_key, it can only openat files under /dev.

    [evdev] gets an ever increasing pile of “helper” libraries (libevdev, libudev, libinput, libratbag, libkilljoy, libreadabuttonpress, libvaluebetween0and1, …)

    Okay, that’s not fair. udev is hotplug, and ratbag is configuring dank gaming LEDs on gaming mice. It makes perfect sense that the kernel reports simple events and userspace (libinput) interprets it in complex ways (touch gestures, calibration, etc.)

    evdev is one of the few parts of Linux that don’t suck, and I’m very happy to have it on FreeBSD too.

    1. 6

      weston-launch is already pretty sane :)

      It’s the decoupling between -launch and the main process being a hard coded exec I have a beef with. Hurts when you have multiple versions installed etc. So yes, I’ve had futile weston debugging sessions boiling down to forgetting that weston-launch does this.

      I took a peak at your plug - now my Rust is a bit non-existing, but to me it look like you can path traverse out of drm and input from those starts_with checks and collect sensitive data from the other device nodes in there? i.e. why xenocara went with a whitelist.

      evdev is one of the few parts of Linux that don’t suck, and I’m very happy to have it on FreeBSD too

      Have you actually seriously worked with it, as in the real thing and not a reasonably clean “we ported the structs and ioctls” and without someone wrapping udev+libevent+device fixup database?

      The cracks doesn’t start to show until you work with input devices that aren’t your basic keyboard and mouse. They widen quickly and large enough to swallow you whole after that. The ‘big box of fun’ input devices that I try whenever I feel the need to lower my spirits cover everything from joysticks that randomly gets exposed as a keyboard and as a joystick depending on what else I have plugged into the bus, mice and keyboards that expose LEDs but then require separate custom hid packets for the changes to activate, etc.

      To clarify my stance: evdev is much too simple for the devices it provides access for - lacking basics like filter controls, ambiguous and unreliable device identity (both collisions and failure to track the same device moving between connected ports), lost relationships (for devices that split up into 2+ separate subdevices). Just look at this small slice of nightmare fuel, a condensed version of what udev is doing.

      1. 1

        Yeah, protecting other devices is not something I bothered to do yet. But it’ll be easy to just open the input and dri subdirectories. A bit unfortunate that the virtual terminals aren’t in a subdirectory, but opening the vt doesn’t take user input.

        About evdev, well, Synaptics touchpad + TrackPoint and Windows Precision touchscreen work fine. I actually added Apple Magic Trackpad support to bthidd and that mostly works too. I also made a little daemon that generates events on a virtual device based on a user script that gets events from other devices.

        We don’t have gamepad support yet… also we don’t have udev anything, only a stub libudev that uses devd for hotplug notifications.

        Is there a real need to classify devices as mouse/keyboard/etc? Why not assume that any device is everything at once? The only meaningful distinction I can think of is touchpad vs touchscreen (both send absolute events)…

        1. 3

          Most gains of knowing the separation is in the user interface and the performance optimization stages, where it can be incredibly noticeable. Since everything is dynamic / hotplug and non-deterministic it’s hard to know if the system is in a usable state or not if you don’t preserve type. Then there’s the threat model that comes with something like a rubber ducky…

          Some generals: For keyboards you want to load/probe for translation tables/state machines, repeat-rate controls / recovery keybindings.

          For mice you want dynamic sample rate controls dependent on the type of your input focus, and with most optical mice today, detect / discard jitter if at rest. The more you can early-discard or memory map instead of queue+copy the better. If you work with accessibility or want to reduce physical motion, pair it with an eye tracker (adding support for that right now).

          For gamepads you really want them disabled at the lowest level until they are actually needed or they can murder your input stack. Something like the PS3 or PS4 controller exposes 30ish analog inputs, each at very high samplerates, even if they’re not used, they get sampled, read, forwarded, queued, copied, and much later discarded.

          touchpad vs touchscreen (there’s a lot here) both devices classes can actually send both absolute and relative events, think of the Z axis or “pressure” (some touchscreens can even give you a rough 2.5D heightmap of what it “sees” while some hide the analysis in firmware). These behave/“feel” better if you align or resample them to the sample rate of the current output display, and there’s big gains if you hook up to CPU/GPU governors. Precision and calibration varies with room temperature and grounding / signal environment.

          1. 1

            Yeah, protecting other devices is not something I bothered to do yet. But it’ll be easy to just open the input and dri subdirectories. A bit unfortunate that the virtual terminals aren’t in a subdirectory, but opening the vt doesn’t take user input.

            I guess it’s not very portable, but in the past I’ve used devfs rulesets[1] in chroots or jails for isolating device nodes for certain daemons.

            [1] https://www.freebsd.org/cgi/man.cgi?query=devfs.rules&sektion=5&n=1

      2. 2

        So I couldn’t tell from skimming this article, does this software at all address the X11-lets-anyone-be-a-keylogger problem?

        1. 5

          This article is only ‘ranty technical notes from when I …’ the full ‘how does this actually solve the X11 and Wayland problems (that I know of)’ needs a much more careful and thorough explanation.

          But yes, the software itself addresses the keylogger problem, the clipboard monitoring problem, the window/screen sharing problem, the display gamma control problem and the window management problem without sacrificing features.

          1. 2

            Where can I find more info on those claims?

            1. 4

              It’s currently scattered in the wiki and the blog posts. it’s a huge topic that I think should be considered in the context of the features each security risk is related to, not in isolation like “no screen reading”, “no keylogging” or the perspective suffers. Therefore, for a coherent comparison - there is a three-article series currently being written with the first one being close to finished. Wait for ‘Arcan vs. Xorg: nearing feature parity’ (followed by ‘at feature parity’ and ‘beyond feature parity’).

              The much condensed basic idea:

              1. The WM explicitly sets routing policy for all input, including the ability to filter, synthesise (fake), broadcast or multicast it.
              2. The WM has access to trust origin from two mechanisms. Trusted client being spawned by the display server process, inheriting IPC primitives. Untrusted clients connecting through a consume-on-use named connection point.
              3. A client connection gets a fixed set of basic primitives, and negotiates for more with the default policy being reject.
              4. The WM can assign different policy- and permission- sets based on trust origin from 2.
              5. User picks the WM (set of scripts).
        2. 2

          While there are many parts to reaching a lofty goal of supposed ‘quality software’, the one that is the implicit target of this post is the value of a portable codebase as a way of weening out bugs (where #ifdef hell or ‘stick it in a VM masked as a language runtime’ does not count).

          Hell of an assumption. What seems more likely?

          • A: portable codebases have less bugs because “the ability to swap out system integration layers as a way of questioning the existing codebase about hidden assumptions and reliance on non-standard, non-portable and possibly non-robust behaviours and interfaces.”
          • B: portable codebases have more bugs because of the increased complexity of satisfying multiple, often conflicting, behaviors and interfaces in different system integration layers.
          1. 1

            This is pretty cool and could drive me to trying out arcan, I wonder what would be needed to build durden on openbsd.

            1. 2

              Can’t find my notes on what I needed but from a clean 6.3 there was not many packages needed (for arcan that is, durden is “only” lua scripts). llvm+clang+cmake for build deps then freetype/mesa/sqlite/egl/gbm along with the in-source stuff for lua/openal.

              The “last mile” stuff is still rather rough around the edges, but we’re just about reaching the whole “sane config presets”, “proper packaging” etc. stage - mechanisms first, then policies :-)