Application level access control

[Rob-NY]

I realize this has been discussed many times in different threads. Today, there are (at least) three options for controlling access to a Jamulus server:

1. Edge Firewall (real firewall appliance, etc)
2. OS Firewall (iptables/nfw, etc)
3. Application level

While there is great debate surrounding this issue, it isn't necessarily a bad idea to provide server operators with some basic tools to manage private servers or react to the occasional bad actor directly using the Jamulus server as opposed to 1 or 2 above (i've personally used 2 for my solution in the past).

With this in mind, I've put together a proof of concept that introduces basic, light-weight access control at the socket level. In a nutshell, it uses two attributes: A "mode", and a "list".

There are two modes: Open and Closed. The list is a list of IP's (address only, not address:port)

In OPEN mode, all packets are ACCEPTED except for those coming from IP's on the LIST.
In CLOSED mode, all packets are REJECTED except for those coming from IP's on the LIST.

All control for this proof-of-concept is handled through the JSON-RPC interface.

I'm interested in people's thoughts on this approach and to gauge whether a PR down the road would even be considered. I'm also looking for server operators who have worked with JSON-RPC who might like to do some testing with me.

[rdica]

Interesting, what specific controls would be managed via JSON-RPC?

[Rob-NY]

Set mode
Add Address
Remove Address
Get status (returns the current mode and all addresses in the list)
Reset (set mode to open, clear all addresses)

[rdica]

Nice, I'll volunteer to test..can we discuss off-list?

[ghost]

This sounds similar to the white-list that has been mentioned on occasion. I would like the white-list part of your idea to be accessible with a simple command line interface also (parameters passed when server or client is started).

[Rob-NY]

It is unlikely to be managed via command line arguments, unfortunately. However, as a system operator, you certainly could write a command line utility or script to send a set of rules to the Jamulus server instance via RPC.

[ghost]

If a white-list or black-list via json is accepted, then a white-list via command line must be accepted when someone decides to do it.

[Rob-NY]

I'm not sure I agree with your premise. Actions taken via a published API do not need to have equivalent start-up command line options. However, I do appreciate your input and will certainly consider your suggestion.

[pljones]

Remember, my view is that any external interface is secondary to the core run time and all should be equal. So I'm now going to say:

• main() should support absolutely every option (that's what's been my "big project")
• all options need to persist across restarts
  • so there's collection of options that gets passed from main() to either the client() or the server() with its initial state from persisted state overridden by command line options
• then, all state information needs to be queryable and updateable through any interface (GUI, JSONRPC, MIDI)
  • then, on exit, gets persisted

We're starting from a long way off all those goals. I'm also finding making the change very hard...

[Rob-NY]

These are all great design goals. But as you point out, we are not there today. So as we try to introduce new functionality, we have to implement it into the existing paradigms. For me, trying to simultaneously address/recognize the issues you’ve identified while introducing new features results in endless spinning around and, to be completely honest, is a bit frustrating.

In this particular issue that the OP asked, I don’t believe firewall state information is actually part of a configuration — and as such would not or should not persist as part of the jamulus config, per se. They’ll be plenty of time to discuss these particulars.

You have been very consistent on your points across a bunch of threads. Is there a rearchitecting effort underway someplace where these foundational issues are being addressed?

[pljones]

Yeah...
https://github.com/pljones/jamulus/tree/feature/next-big-thing-for-settings
I squashed, to make keeping up to date easier. I need to split out into a series of separate, sane changes... (I get too easily distracted by "whilst I'm here" changes - so the whole of the diff to master is ridiculously messy right now.)

[Rob-NY]

For those interested in this topic, I have an initial version of this concept that can be found here (https://github.com/Rob-NY/jamulus/tree/feature_firewall). The JSON-RPC method documentation is included. Thanks to @rdica for real-life session testing and for testing IPv6.

In a nutshell, access control is governed by two elements: the mode (there are two), and the IP list.

Mode 0 is "open mode". All clients will be permitted EXCEPT those on the list.
Mode 1 is "closed mode". All clients will be rejected EXCEPT those on the list.

RPC methods available are documented in docs/JSON-RPC.md and include:

jamulusserver/setFirewallMode
jamulusserver/getFirewallStatus
jamulusserver/addFirewallAddress
jamulusserver/addFirewallAddresses
jamulusserver/removeFirewallAddress
jamulusserver/resetFirewall

All IP addresses added/removed from the list should be strings in standard IPv4 notation x.x.x.x or IPv6 notation with no brackets. This implementation ONLY supports IP addresses -- no port qualification. This is by design.

Further, no attempt was made to actively remove the connection in Jamulus. Instead, blocked clients will timeout just as they would with an edge or OS-based firewall. For now, this is also by design.

Thoughts and feedback are welcomed.

FWIW: This is implemented using string hash comparisons. I realize I can use other, potentially more efficient means, and these will be considered down the road.

[ann0see]

It's strange to suddenly be disconnected without obvious reasons.

[Rob-NY]

The operator can always say “bye-bye” before he clicks the button. :-). It will be very difficult to do these things because chats and other client notifications could, themselves, be blocked by the ACL rules unless we provide a sync delay (ACL block inbound and outbound so audio to the client would be immediately cut off even if they still appear as connected during the timeout period).

This is great discussion — and exactly why we are doing it here and not as a PR.

[rdica]

@ann0see Define obvious reasons. A user can't know one way or another why they were disconnected. Too many variables. Too many hops between user and server.
It's a network, strange things happen all the time.

It should be left up to the server operator to decide on any notification as @Rob-NY suggests above.

[ghost]

There is no need to inform someone that they have been put on a black list (black, not block) because Nothing else should happen. It's a separate action to actually block someone. -- If blocking someone is done in real time, then, that is when you worry about courteousness.

[pljones]

There is no need to inform someone that they have been put on a black list (black, not block) because Nothing else should happen. It's a separate action to actually block someone. -- If blocking someone is done in real time, then, that is when you worry about courteousness.

And how courteous comes down to why they're being blocked...

[ann0see]

Also maybe not use firewall but maybe something like AccessList to avoid ambiguity with the system firewall.

[Rob-NY]

Yeah, I've already changed it internally to Access Control List (ACL) which is a better descriptor.

[ghost]

I noticed "internal access control list" in the source code. If this internal Access Control List could be loaded with data from a config file at server start-up, this would make whitelist/blacklist accessible from the command line.

[Rob-NY]

@DavidSavinkoff - I know you want to be able to control this via the command line. It is unlikely I will support ACL via the jamulus startup command line anytime soon, but you still have other command line options -- especially if you're running linux or mac. You can use netcat (nc) to send batches of commands to the server via JSON-RPC. For example, say you want to configure for a closed server with two authorized IP addresses. You could create a file called "lockdown.rules" that has these lines:

{"id":"access","jsonrpc":"2.0","method":"jamulus/apiAuth","params":{"secret": "your_rpc_secret_here"}}
{"id":"reset","jsonrpc":"2.0","method":"jamulusserver/resetFirewall","params":{}}
{"id":"mode","jsonrpc":"2.0","method":"jamulusserver/setFirewallMode","params":{"mode": 1}}
{"id":"add","jsonrpc":"2.0","method":"jamulusserver/addFirewallAddress","params":{"address": "192.168.10.100"}}
{"id":"add","jsonrpc":"2.0","method":"jamulusserver/addFirewallAddress","params":{"address": "192.168.10.101"}}

You could create as many of these rules files as you need to run your operations.

Next, create a bash script to send these to the server by creating another file called "sendrules" that has the following:

#/usr/bin/env bash
nc -N 127.0.0.1 9001 < $1

...replace 127.0.0.1 with the IP your server is listening on for RPC, and 9001 to whatever port you've configured for RPC.

Then, you can simply send the server the firewall commands (via the command line) using:

sh sendrules lockdown.rules

or

sh sendrules AnotherRuleSet.rules
etc...

I don't want to be condescending as I do not know your experience level, but there are many other ways to economize this operation and make it even easier. I'm happy to help further if necessary.

My point is, you can control the ACL via the command line even if not part of the startup options. Further, if you do happen to use the same rules each time you start Jamulus, you can wrap the entire Jamulus startup process in a script.

Hope this can get you started using the command line today.

[rdica]

A sample systemd unit that incorporates setting ACL controls after service startup, like @Rob-NY describes:

cat /etc/systemd/system/jamulus-ACL-server.service

[Unit]
Description=Jamulus-ACL-Server
After=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
Restart=on-failure
RestartSec=5
User=ardy
StandardOutput=journal
StandardError=inherit
SyslogIdentifier=jamulus
ExecStart=/home/ardy/bin/jamulus-ACL -6 --server -p 22324 --nogui --discononquit \
--welcomemessage "<h1>Welcome!</h1>Play some music!" --numchannels 10 \
--directoryserver anygenre2.jamulus.io:22224 --serverinfo "A Jamulus Server;Anytown;us" \
-R /data/jamulus/recordings --norecord --jsonrpcport 55324 --jsonrpcsecretfile /data/jamulus/html/rpcfile \
-l /data/jamulus/logs/jamulus-server-ACL.log -T -P
ExecStartPost=/bin/bash -c 'sleep 2 && /home/ardy/bin/rpc-firewall-rules.sh -fw'

[Install]
WantedBy=multi-user.target

[ghost]

Thank you for the replies, this helps. Maybe all that is needed is a few documented examples.
What is involved getting "your_rpc_secret_here" to work? Is this simple or do I need to set up a service.
{"id":"access","jsonrpc":"2.0","method":"jamulus/apiAuth","params":{"secret": "your_rpc_secret_here"}}

Edit: This question is addressed in the Jamulus JSON-RPC Documentation jamulus/docs)/JSON-RPC.md