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?

[Bob_Zimmerman]

Took a bit longer than I thought to finish shaving some other yaks and get back to directly working on this project. I'm happy to report I was able to figure out enough about menus to allow for the creation of new objects! It's still very much a work in progress, and I need to add some client-side data validations (if you build a new object and don't give it a name, that should present an error on the client side, rather than trying to push a nameless object and making the management hand me an error), but it's functional for all of the types I have detail views for.



The disabled entries in the menu are items I don't have a good detail view for yet. The issue is mostly that I don't yet know how I'm going to handle editing references from one object to another. I have some ideas, but other things have been higher priority.

So to recap, I now have:

• Object and rule download
• Object detail view and editing
• Creating new objects
• Drag-and-drop from object list into rules and from rule field to rule field for sources, destinations, and services
• Publishing and discarding sessions

The first three are subject to some limitations (as I said, I don't yet have good detail views for some object types, and I use the detail view for editing, and editing for creating new objects), but they work in general.

I do not yet have:

• Search for objects or rules
• Deleting objects
• Adding rules or sections
• Rearranging rules or sections
• Editing rule fields other than source, destination, and service
• Deleting rules or sections
• Any sort of view of progress for in-flight tasks
• Any sort of change counter to let you know how many things you are about to publish or discard
• Adding new policy packages or access layers
• Editing policy packages or access layers
• Deleting policy packages or access layers
• Pushing policy
• Anything to do with Threat Prevention
• Anything to do with logs

The client as it stands today is 1.3 MB zipped, 6.2 MB ready to run, built for both amd64 and aarch64. It's 6933 lines as written, 6127 if I remove blank lines and block comments. Shockingly (to me, anyway), 792 of those lines are just a single closing brace.



I'm finding I really like Swift's trailing closure syntax, and inline closures in general. The ability to do `let objectName = { <some tiny function here> }(<arguments>)`is pretty slick, as is the ability to add getter and setter methods and property observers to any property:

var someValue: Int = 0 {
	get { ... },
	willSet(newValue) { ... },
	set(newValue) { ... },
	didSet { ... }
}

Objective-C selectors (needed for double-click, menus, and more) are currently kind of painful for me, but I think I'm starting to understand how they actually work.

[Bob_Zimmerman]

While figuring out some menu stuff, I decided it's time to learn more about how localization works on macOS (this was actually to help me reliably place the "Add Object" menu in the menubar). Turns out Xcode has some really nice features to help find localization issues:



Xcode lets you force applications to run in a particular locale, and it provides several virtual locales which do interesting things to localized strings. This particular one sets the layout direction to be right-to-left, and flips all localized strings to also be right-to-left. This idea is to let you find spots where the layout would break if the application were running in a RTL locale, but without requiring you to actually speak such a language.

Localization in general involves taking language-specific and culture-specific resources, and replacing them with references to a table. You should then be able to make a new table for each language you want to translate the application into without changing anything about the application code itself. The system checks its list of languages preferred by the user, and picks the highest one offered by the application. The application then uses that table for all of the table references.

This particular virtual locale reverses strings it is given. For example, the "Add Object" menu, the window's "Disconnected" subtitle, and all of the categories in the sidebar. A lot of the strings come from data provided by the management server, though. Those strings print exactly how they are downloaded.

As you can see in the screenshot, I still have a few layout issues to work out. For example, the column headers are left-justified rather than leading-justified.

[Bob_Zimmerman]

I've figured out enough about contextual menus to allow for object deletion.

This required more "fun" with Objective-C selectors. Selectors are basically function calls, but you can't pick values to pass to them. The UI framework picks the arguments automatically. Took me a while to figure out how to work within that constraint. Just like saving changes, deletion is disabled if you are disconnected, or connected in read-only mode.

Working on object search and a good way to edit objects which reference other objects (groups, access roles, etc.) next. Then I'll tackle editing rules beyond just adding objects to the source, destination, and service columns.