SmartDashboard on macOS

[Bob_Zimmerman]

Ran into some issues, which stalled my progress for a while. I decided the fix was to rewrite most of the UI. Still not done with that, and still not past the issues in question, but I think I'm getting there.



I am now using AppKit more directly rather than going through SwiftUI. With this change, I lose some nice development features, but I gain a lot of capabilities which I hope to put to good use soon. For example, I now have a toolbar at the top of the window. In this screenshot, it only has a single button which hides or shows the sidebar, but I'm working on a few other things to put there.

I really like the new "subtitle" feature added in the upcoming macOS version. To handle multiple SmartCenters, I started using a type of document which plays nicely with the database engine I'm using. This window is showing a document I named "2200", which is saved locally on my workstation. The subtitle shows the username and server it represents.

Made some big changes to how the sidebar works. Not thrilled with how it looks yet, but I am thrilled with how well it works so far. It's everything I like about old SmartDashboard's objects list and everything I like about new SmartConsole's objects list.

[Bob_Zimmerman]

Made some advances and thought I would show them off.



Dark mode actually worked perfectly right out of the gate.

• Dramatically improved login. That's the phone button at the far left of the toolbar. The button and the subtitle tell you whether you are currently connected or not (here, I'm not).
• Added support for object colors (had to build a bunch of color swatches in my project file, but only a single line of code had to change to use them). I still have some tuning to get the colors a little different between light mode and dark mode, but that's just simple tweaks to the named swatches.
• Added action icons. For now, I've gone with a couple of different shapes to improve recognizability for colorblind users, or for people who run grayscale for whatever reason. It's a little hard to see in the low-res screenshot, but accept is a green circle with a checkmark cutout, drop is a red trashcan, and reject is a red hand.
• Started work on a detail view/editor. I need to figure out a better way to do this, as the way I have it now is really tedious to work with.
• Tested a lot more, including support for larger policies. For now, the biggest I've tried is 3600 rules, but it worked perfectly.

Now that macOS 11 is officially out, it's the minimum version I'm targeting.

[EricAnderson]

Nicely done! Looks like it's time to upgrade my Hackintosh VM again ;)

-E

[Bob_Zimmerman]

No screenshots to really show this off, but a small update.

I have just made my first successful API call to change the properties of an object based on changes made locally in my client.

While what little I have works very nicely, write mode admittedly isn't very functional yet. For now, it just allows changes to objects' names, comments, and colors. I have to write a lot of cases for what properties the different object types have. Don't want to try to change the network mask on a TCP service, after all.

I also don't yet support publishing. I need to figure out a way to convey status back to the user.

[Bob_Zimmerman]

Spent a while completely rewriting my entire import architecture and my entire object model. Previously I had been using one single object definition for everything. Hosts, networks, services, applications, even rules. This is gross for a lot of reasons, but I found it necessary, as the API often hands you a UUID with no information about the type of object that UUID represents. Further, there is an object for "Any", and exactly the same object is used for sources, destinations, VPN communities, and so on. Well, with the help of a few articles on interesting ways to extend Swift's Codable feature, I figured out a way around that. Took me a few weeks, but the end result is about 20% lower memory footprint and file sizes for the local copy of the data.

While I was at it, I worked out my own ordering criteria for ordered lists of things like access rulebases. That worked very nicely, so I also now have proper ordering of empty sections.

NAT rule display is currently broken. I adapted the rule outline to the new model for access rules, but NAT rules are now different enough I need to spend more significant time getting them working. It's slightly complicated by the fact the automatic NAT sections are shared between many policies. Pretty sure I'll have it hammered out this week.

Edited to add: Turns out NAT rule display was easier to fix than I thought. 75 new lines, 11 changed, 53 deleted lines, and I see a few opportunities to clean things up further. Not bad! The new object model is now fully integrated with complete feature parity with the old model.

[jflemingeds]

At some point this is going to be a very round wheel. :)

[Bob_Zimmerman]

At some point this is going to be a very round wheel. :)

At some point, sure. For now, I figure I have about 20% the functionality of SmartDashboard. Lots left to add, but it's mostly view-side code in MVC. The object model changes put me in a better position to be able to add those things without running into limitations later.

Stuff I don't have yet:

• Publishing - Mostly waiting on me to figure out a way to convey progress to the user.
• Pushing policy - Waiting on publishing and progress conveyance.
• Adding objects - Waiting on publishing.
• Rule reordering - Waiting on me to figure out how drag-and-drop works with NSOutlineView.
• Rule modification - Waiting on me to figure out how to represent the fields for modification.
• Adding rules - Waiting on rule modification, as they're mostly the same thing.

There are a few other small weirdnesses, but those are the major limitations right this second. The progress meter is probably the next thing I'm going to work on.

Edited to add: Well I thought publishing was just waiting on a way to convey progress to the user, but it turns out the API for tasks is far, far weirder than I had expected. Each task is an object of the type "task" with a UUID like any other object (which you can use to find the object personality of the task via 'show object', but you can't see the progress) ... then a separate "task-id" which is a different UUID which you need to use to actually find it via 'show task'.

On the plus side, if we don't care about feedback from the publish operation, I have that functional right now. :p

[Bob_Zimmerman]

Gave up on the progress meter for now, and learned to do this instead:



I now have support for dragging objects from the sidebar into the source, destination, and service fields of rules, and the objects actually get added to the rule via the API. In that screenshot, I'm dragging ".github.com" to the destination of rule 3. It's pretty fragile right now, as I'm still learning about how to represent drags as different data types and how to filter the drop targets based on what is being dragged. Right this second, you can absolutely do nonsensical things like dragging a service into the destination of a rule. Still, it's visible progress!

I have also added detail views and write support for a bunch of object types. In endpoints, I've got address ranges (multicast or not), DNS domains, hosts, networks, wildcards, security zones, and dynamic objects. No support yet for access roles, groups, or firewalls. In services, I've got TCP, UDP, ICMP, ICMPv6, DCE-RPC, and RPC. Still working on IP protocols, groups, and applications/sites.

Still no support for building new objects, building new rules, rearranging rules, removing objects from rule fields, or editing fields other than the source, destination, and service. Lots of those are relatively well-defined features, though. Much less daunting than the original "figure out how to show rules at all".

A universal amd64+aarch64 release build zips down to 1.2 MB, so it should still just barely fit on a floppy. ;)

Edited to add: And this weekend, I figured out pasteboard data types. You can no longer drag services to the source or destination of a rule, or endpoints to the service of a rule. I also got field-to-field drag-and-drop working, though only for one item at a time. I think that's an acceptable limitation for now. On to other things.

[Bob_Zimmerman]

Finding some rough edges when it comes to application/site objects and their relationships with categories. Suspending my work on that for now.

I think I've figured out how to make new objects. It leverages the detail view and object editing work I've done so far, with a tiny modification to recognize when the object is new. Still learning about menus, but I think I'll have a basic version working soon.

[Bob_Zimmerman]

Now that I have a good way to build an MDS for testing, I'm starting to work with the multi-domain parts of the API. This leads to a big question:

How should connecting to an MDS work?

It would be easiest from a development standpoint to spot that I'm connecting to an MDS, throw an error to ask the user to pick a domain, then connect only to that domain. From there, it's just like a SmartCenter. Everything in that CMA gets cached to the local database, saved to a file, and so on.

With a fair amount more work, I think it would be possible to build a connection to every domain you have permission to access (including the MDS itself and the global meta-domain), and use that to pull all of the data from every domain into the same database (retaining the domain each object came from, of course). This would allow for extremely rapid switching between domains (on-par with the speed of switching between policies). Separate files per domain would let you view multiple domains at once in different windows, though.

So what does everybody think? Separate file per CMA, or one big file for all CMAs on an MDS?