3

I'm potentially interested in using Linux capabilities for a program (specifically, cap_net_bind_service to allow a program to bind to a TCP port less than 1024).

However, I'd like to do it for a program that is C# running under Mono. Normally, I think that would mean the Mono interpreter itself would need to have the capabilities set on it, rather than the whatever.exe program that it runs.

However, Linux also can have Mono binary kernel support, via the kernel binfmt_misc mechanism.

So, does the kernel binfmt_misc mechanism work with capabilities? That is, so that a particular binfmt_misc-enabled executable file can run with particular capabilities set.

Sam Protsenko
  • 14,045
  • 4
  • 59
  • 75
Craig McQueen
  • 41,871
  • 30
  • 130
  • 181

1 Answers1

0

Normally, I think that would mean the Mono interpreter itself would need to have the capabilities set on it[...]

It would take binfmt_misc out of the question if you set capabilities on the process tree in question, rather than on the files.

See cap_set_proc(), and tooling for manipulating it. For instance, if you were using systemd:

[Service]
ExecStart=/usr/bin/mono /path/to/your/executable.exe
User=your_service_account
Capabilities=CAP_NET_BIND_SERVICE
Charles Duffy
  • 280,126
  • 43
  • 390
  • 441
  • Then what does [`setcap`](http://linux.die.net/man/8/setcap) do? For example, see [this answer](http://stackoverflow.com/a/414258/60075). – Craig McQueen May 13 '15 at 00:34
  • Heh. Okay, that's a whole different branch of the capabilities tooling than the part I was aware of. However, it's not a branch you need to use -- you can use the process-tree forms, not the file-based forms, if that's a better fit for your use case. – Charles Duffy May 13 '15 at 00:36
  • So in practical terms, I could do this if I used systemd rather than sysvinit to start processes? That is, it seems that sysvinit lacks control of capabilities? – Craig McQueen May 13 '15 at 00:45
  • There are more options than that -- if you set the inheritable flag, then you could put the capability on a compiled launcher, and invoke that from your sysvinit scripts. – Charles Duffy May 13 '15 at 00:48
  • I'll be curious to see what other answers you get here; I'm not interested enough to actually test behavior with binfmt_misc, but it's probably worth doing. – Charles Duffy May 13 '15 at 00:49
  • Just as an aside -- another way to work around this would be to have iptables rewrite the destination port on inbound packets to something your service _could_ bind to directly. A hack, to be sure, but... *shrug*. – Charles Duffy May 13 '15 at 00:51
  • I tried `iptables -A PREROUTING -t nat -p tcp --dport 80 -j REDIRECT --to-port 8080` but I found that also affects forwarded packets (i.e. for a device doing tethering, it redirects clients' web accesses to the unit's own HTTP server), which is not what I want. – Craig McQueen Sep 03 '15 at 23:56
  • I think what you're describing about "setting capabilities on the process tree" doesn't work, because the Linux kernel still restricts capabilities according to the capabilities set on the file to be executed. See [this answer](http://stackoverflow.com/a/16429330/60075). – Craig McQueen Sep 04 '15 at 00:32
  • @CraigMcQueen, capabilities were available (and I was using them!) back before SELinux was widely adopted, and thus before security-contexts-as-filesystem-metadata were a thing that existed. I suppose it's conceivable that that support may have been actively ripped out, but... well, that doesn't happen often, even when an alternate approach is considered best practice. – Charles Duffy Sep 04 '15 at 02:01
  • The [systemd documentation for `Capabilities` option](http://www.freedesktop.org/software/systemd/man/systemd.exec.html#Capabilities=) says "Note that these capability sets are usually influenced (and filtered) by the capabilities attached to the executed file." – Craig McQueen Sep 04 '15 at 02:05
  • Sure. I'm merely pointing out that there used to be support for capabilities without filesystem influence, and thus, I'm certain that it still exists. I mean, not all filesystems have xattr support enabled in the first place; Linux hasn't dropped compatibility with ext2, or with ext3 filesystems with that (now-on-by-default) flag disabled, much less non-ext* filesystems altogether that never had such support to begin with. – Charles Duffy Sep 04 '15 at 02:18