Call for testing: fkill


#1

fkill is available in the beta channel:

sudo snap install --channel=beta fkill
sudo snap connect fkill:process-control :process-control
sudo snap connect fkill:system-observe :system-observe

Please let me know if you run into any issues!


Requesting interfaces autoconnection for fkill
#2

Tested on Ubuntu 17.10 here. What a lovely little application.

Works a treat here!

image


#3

@popey where you able to kill the processes? Doesn’t this have to be classic in order to do that?


#4

there are the “process-control” and “system-observe” interfaces (the htop snap uses them) with which you should be able to do everything that is needed here in a confined snap … though note that the above instructions also say --devmode … so i guess @popey is simply running it unconfined atm.


#5

@elopio @ogra I have been running into issues running it confined. Using the process-control and system-observe interfaces, I get a few problems. The program isn’t able to start due to this error:

= AppArmor =
Time: Dec  6 00:15:04
Log: apparmor="ALLOWED" operation="open" profile="snap.fkill.fkill" name="/run/systemd/resolve/stub-resolv.conf" pid=20252 comm="node" requested_mask="r" denied_mask="r" fsuid=1000 ouid=102
File: /run/systemd/resolve/stub-resolv.conf (read)
Suggestions:
* adjust program to use $SNAP_DATA
* adjust program to use run/shm/snap.$SNAP_NAME.*
* add one of 'firewall-control, network, network-bind, network-control, network-observe' to 'plugs'

I’m not sure what this could be, as the program shouldn’t access local files or make any network requests. If I add one of the given interfaces, it starts, but gives these errors and can’t close any processes:

= AppArmor =
Time: Dec  6 00:22:46
Log: apparmor="DENIED" operation="ptrace" profile="snap.fkill.fkill" pid=20650 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined"
Ptrace: peer=unconfined (trace)
Suggestions:
* adjust program to not trace processes
* do nothing if program otherwise works properly

= AppArmor =
Time: Dec  6 00:22:46
Log: apparmor="DENIED" operation="open" profile="snap.fkill.fkill" name="/proc/1/cmdline" pid=20651 comm="ps" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
File: /proc/1/cmdline (read)
Suggestion:
* adjust program to not access '@{PROC}/@{pid}/cmdline'

Sorry for posting a bunch of errors, I’m not really sure how to fix them. Perhaps it would be better to just use classic confinement?


#6

Just add “network-bind” to your apps interfaces list for this one …

Regarding ‘@{PROC}/@{pid}/cmdline’ i think the system-observe interfaces grants access to this (though perhaps not for PID 1 (which is systemd)).

For tracing there is the system-trace interface, but i’m not 100% sure this is the right interface for userspace ptrace, perhaps @jdstrand and chime in here …


#7

@{PROC}/@{pid}/cmdline is covered by system-observe, yes.

As for the ptrace trace unconfined-- this is not covered by system-trace (that interface is for kernel tracing). ‘ptrace (trace) peer=unconfined’ would give the application total control of the system since a root running process could ptrace unconfined to gain control of a root running unconfined process to then make it do anything.

That said, I don’t think you actually need this for your snap. This denial:

apparmor="DENIED" operation="ptrace" profile="snap.fkill.fkill" pid=20650 comm="ps" requested_mask="trace" denied_mask="trace" peer="unconfined"

is actually special for two reasons:

  1. ps requests ‘ptrace (trace)’ even though it isn’t tracing other processes. Unfortunately, this is due to the kernel overloading trace such that the LSMs are unable to distinguish between tracing other processes and other accesses. Fortunately, ps doesn’t actually need to trace other processes so the denial is harmless in the context of ps
  2. the act of reading /proc/1/environ triggers a ptrace denial. fkill shouldn’t be messing with init anyway, so this is harmless too

I installed fkill and manually added all the security policy as if the snap used plugs: [ network, process-control, system-observe ] and those interfaces were connected and I was able to:

  • kill processes in interactive mode just fine
  • in non-interactive mode, if I did sudo sleep 600 in one terminal and then 'sudo fkill ’ in another it didn’t work, but sudo fkill -f <pid> did. This is unrelated to the ptrace denial, because if I add a ptrace rule to the policy (and remove the explicit deny system-observe added), it operated the same way. This seems to have something to do with running the sleep under sudo, when doing sudo -i followed by sleep 600 I was able to kill the process just fine.
  • in non-interactive mode, if I did sudo fkill sleep then it said Error killing process. Would you like to use the force? I said ‘yes’ and then it traced back:
    AggregateError: 
      Error: Killing process sleep failed: spawn killall ENOENT
          at Promise.all.then (/snap/fkill/12/lib/node_modules/fkill-cli/node_modules/fkill/index.js:40:10)
      at AggregateError (/snap/fkill/12/lib/node_modules/fkill-cli/node_modules/aggregate-error/index.js:19:3)
      at Promise.all.then (/snap/fkill/12/lib/node_modules/fkill-cli/node_modules/fkill/index.js:40:10)
      at process._tickCallback (internal/process/next_tick.js:109:7)
    

Running sudo snap run --shell fkill, I discovered:

$ which killall
$
$ ls -l /usr/bin/killall
ls: cannot access '/usr/bin/killall': No such file or directory

What is happening is that the core snap, which is the runtime for your snap, doesn’t ship ‘killall’. You need to use stage-packages in your snapcraft.yaml to stage the ‘psmisc’ package which will then ship $SNAP/usr/bin/killall in your snap.

Can you update your snapcraft.yaml to use:

...
apps:
  fkill:
    command: command-fkill.wrapper
    plugs:
    - network
    - process-control
    - system-observe
...
parts:
...
  mypackages:
    plugin: nil
    stage-packages:
    - psmisc

then rebuild, install, make sure all the interfaces are connected (eg, sudo snap connect fkill:process-control && sudo snap connect fkill:system-observe (and verify with ‘snap interfaces’)), then try again?


#8

Thanks @jdstrand, the snap seems to be working great now! I’ll keep all this in mind when debugging snaps in the future.

I’ve updated the installation instructions in the OP.