apparmor profile?

[chrt223]

... because it sounds like a must-have for such a project. Don't you think?

[woodser]

This was generated by AI as a starting point. Maybe someone can test and develop it into a PR:

"This profile should be placed in /etc/apparmor.d/haveno and enforced using apparmor_parser. It limits Haveno's access to only necessary files and resources."

#include <tunables/global>

profile haveno /path/to/haveno-binary {
    include <abstractions/base>

    # Allow reading necessary system files
    /etc/passwd r,
    /etc/group r,
    /etc/ssl/** r,

    # Allow access to Haveno's working directories
    @{HOME}/.haveno/ rwk,
    @{HOME}/.haveno/** rwk,

    # Network access
    network inet stream,
    network inet6 stream,

    # Allow execution of required binaries
    /bin/bash ix,
    /usr/bin/java ixr,

    # Deny dangerous actions
    deny /proc/* w,

    # Lock the profile
    deny /** wklx,
}

[boldsuck]

Since Haveno runs with user privileges and HiddenService can't be attacked from the network side, I see it as 'nice to have' but not as a 'must-have'.¹

For seednodes running as system services, it is more useful. (systemd hardening options are available.)

¹Even for a multi-million dollar org like TorProject, it is a challenge to provide apparmor or selinux profiles that work on hundreds of distros.

[chrt223]

Any file Haveno can read is a potential data which can be exfiltrated (and consequently a potential de-anonymization factor)

With the below profile, based on a public .deb I could boot the app', Tor and browse the markets (but no transaction tested).

See below for various comments this calls for:

abi <abi/4.0>,
#include <tunables/global>

# DNS domains identified during bootstrap.
# cakewallet.com.
# nodes.hashvault.pro.
# monerodevs.org.
# node.monerodevs.org.
# node.sethforprivacy.com.
# p2pmd.xmrvsbeast.com.
# rino.io.
# rucknium.me.
# sethforprivacy.com.
# xmr-node.cakewallet.com.
# xmrvsbeast.com.

profile haveno /opt/haveno/bin/Haveno {
    include <abstractions/base>
    include <abstractions/X>
    # /etc/fonts/*
    include <abstractions/fonts>
    # /usr/share/themes/*
    include <abstractions/gtk>
    # ~/.config/gtk-3.0/*
    include <abstractions/gnome>
    # ~/.cache/mesa_shader_cache/*
    include <abstractions/mesa>
    # ~/.local/share/glib-2.0/schemas/*
    include <abstractions/freedesktop.org>
    # ~/config/dconf/user
    include <abstractions/dconf>
    # org.freedesktop.DBus Hello
    include <abstractions/dbus-session-strict>

    # Allow reading necessary system files (taken from the sample, not sure these are actually necessary)
    audit deny /etc/passwd r,
    audit deny /etc/group r,
    audit deny /etc/ssl/** r,

    # Allow access to Haveno's working directories
    owner @{HOME}/.haveno/{,**} rwk,
    owner @{HOME}/.local/share/Haveno-reto/{,**} rwk,

    # todo: these should not be bundled binary, see tails' version
    owner @{HOME}/.local/share/Haveno-reto/xmr_mainnet/tor/tor ix,
    owner @{HOME}/.local/share/Haveno-reto/xmr_mainnet/tor/lib*.so* rm,
    owner @{HOME}/.local/share/Haveno-reto/monero-wallet-rpc ix,

    # todo: ~/.local/share/Haveno-reto/monerod : 25MB (!) and 10a1b767b doesn't exists
    # monero-wallet-rpc 30MB (should be 16MB)
    # tor 0.4.8.13 (git-e153e72c01315f86) , 3.4MB
    # meanwhile official tor 0.4.8.10 is 2.7M

    # todo: w would conflict with monerod
    owner @{HOME}/.shared-ringdb/lock.mdb r,

    # X/input
    owner /{,var/}run/user/[0-9]*/at-spi/bus* rw,
    owner /{,var/}run/user/[0-9]*/bus rw,

    /opt/haveno/lib/** rm,
    /opt/haveno/lib/runtime/lib/jspawnhelper ix,

    # Network access
    network inet stream,
    network inet6 stream,

    # Allow execution of required binaries
    /bin/bash ix,
    /usr/bin/dash ix,
    /usr/bin/java ixr,

    # is Tor running
    /usr/bin/ps ix,
    /dev/tty r,
    /sys/devices/system/node/ r,
    # todo: avoid
    @{PROC}/uptime r,
    @{PROC} r,

    @{PROC}/cgroups r,
    owner /sys/fs/cgroup/user.slice/user-[0-9]*.slice/user@[0-9]*.service/app.slice/*.scope/memory.max r,
    @{PROC}/@{pid}/{mountinfo,cgroup,stat,cmdline} r,
    @{PROC}/@{pid}/coredump_filter rw,
    @{PROC}/@{pid}/net/if_inet6 r,
    @{PROC}/@{pid}/fd/{,*} r,
    @{PROC}/sys/dev/i915/perf_stream_paranoid r,

    owner /tmp/hsperfdata_*/{,[0-9]*} rw,

    /sys/kernel/mm/hugepages/{,*} r,
    /sys/kernel/mm/transparent_hugepage/enabled r,

    /etc/nsswitch.conf r,

    # after accepting the agreement (Tor bootstrapping/DNS resolution ?)
    /etc/hosts r,
    /etc/host.conf r,
    /etc/resolv.conf r,

    # Tor connection
    /proc/sys/kernel/pid_max r,
    # ptrace (read,trace,readby,tracedby) peer=@{profile_name},
    # todo: should be @{profile_name}
    ptrace (read,trace) peer=unconfined,
    network netlink raw,
    network inet dgram,
    network tcp,

    # useless
    deny /usr/bin/dpkg x,
    deny /usr/bin/rpm x,
    deny /usr/bin/gnome-session-inhibit x,

    # Deny dangerous actions
    audit deny /proc/* w,

    # big problem: hardware fingerprint
    /sys/devices/pci[0-9]*/**/{vendor,device,revision,config,uevent,subsystem_vendor,subsystem_device} r,
    # hardware fingerprint
    /sys/devices/system/cpu/cpu0/microcode/version r,
    # geo fingerprint
    /etc/timezone r,

    # Reading cwd seems needed, why?
    # Running from /tmp
    /tmp/ r,

    # why?
    owner /{,var/}run/user/*/dconf/user w,

    # why ?
    deny dbus send bus=session path=/org/gtk/vfs/mounttracker interface=org.gtk.vfs.MountTracker member=ListMountableInfo,
    deny /etc/pulse/client.conf r,
    deny /run/user/[0-9]*/pulse/ r,
    deny /dev/shm/ r,

    # why?
    # requiring `/usr/lib/systemd/systemd --user` environment (/proc/<systemd-pid>/environ) and others ?

    # why?
    # trying to trace "signal-desktop", why ?
}

First an for all, regarding binaries generated by the .deb, see #1582

Other than that regarding user fingerprinting and sensitive accesses:

• Access is attempted against a variety of peripheral (for DRM purpose?), ie : /sys/devices/pci[0-9]*/**/{vendor,device,revision,config,uevent,subsystem_vendor,subsystem_device} and the CPU too (/sys/devices/system/cpu/cpu0/microcode/version). Other user-specific files include /etc/timezone + resolv.conf (understandable) and /etc/hosts.

=> If a code-execution led an attacker to exfiltrate data, these alone are already helping a lot to profile a user.

• There is some dbus MountTracker attempts (probably implied by GTK itself) but also access to pulseaudio.

=> There may be a way to forbid recording while allowing notification beeps. Otherwise, denying pulse/microphone, for a default profile could be a good security precaution.

• Detecting Tor status is more intrusive than it should: Listing process is very sensitive and trying to look for the environment of systemd --user also is. I don't know if it's related to specific PID assumption (or cgroups?) but I found this build of Haveno consistently tried to ptrace the signal-desktop process.

=> Unbinding Haveno process and Tor process could reduce this profile (and consequently the attack-surface) by half.

• NB: There is little reason to call, package manager (dpkg / rpm) [and we are not talking about hundreds of distros.]

=> Best to avoid it unless necessary. It's generally not a task for the app itself.

[boldsuck]

Haveno-reto

So first of all you are confusing two projects. retoaccess1 (Haveno-reto) =! haveno-dex
That would be the first challenge for apparmor profiles. Each mainnet has to adapt them itself.

Provided Tor binaries and automatically generate a HiddenService is for the user's convenience.
But you can, like me, create a HiddenService ifor Haveno n /etc/tor/torrc & use your system Tor via TorDirectBind.

If you have general security improvements, feel free to submit PRs to haveno-dex or bisq.