[UDP Socket Support]
Support connected UDP sockets to the same degree that TCP sockets are supported. Additionally,
add support for non-connected UDP sockets on a per-packet basis.
Non-connected sockets are definitely more difficult to support because they do not conform to
the simple nature of a connected socket. Each packet that is sent/received could be from or to
a different remote host, and each such remote host should require separate authorization. The
user interface for authorization alerts will need to adapt, and a white/black list of remote
hosts will need to be stored on a per-non-connected udp socket basis.
Update 2007.03.12: Added support for connected udp sockets.
[Unix Domain Socket Support]
Support unix domain sockets, as much as possible, to the same degree that TCP sockets are
supported. Obviously, endpoint IP addresses and port numbers are replaced with file paths,
but the basic premise is largely the same.
The main challenge will be that of adapting the authorization alert interface. Additionally,
the rule evaluation system will need to be adjusted to support unix domain sockets, as will the
"connection" tab of the rule edit panel.
[Customizable Font Settings]
Allow the user to select a font and size to be used by GlowWorm.app and any plugins it is
Replace English-specific, hard-coded strings with localizable references so that other languages
can be supported.
A process chain would allow finer-grained control when specifying which application a particular
rule applied to. For example, instead of specifying that a particular rule applied to nslookup,
one could specify the entire process chain leading up to the execution of nslookup, such that
a malicious program that tried to exploit a vulnerability in nslookup would not have the same
access as the local user running nslookup in Terminal.app, if the malicious program was running
as a process for the user or even as root.
FileOps encompasses restricting and logging file operations beyond the simple unix permissions.
In a passive mode, file operations for a given file, or all of the files within a given directory,
would be logged. Additionally, access restrictions could be placed on a given file, or all of the
files within a given directory. These restrictions and logging could be tied in with process
chains to truly lock down a machine from nearly any imaginable threat.
Define filters and transforms to be applied to data as it is sent/received. For instance, a
packet could be prevented from being sent if it contains certain data, or an incoming packet
might be modified as per a transform.
[Rule Merging in Rule Editor]
Merge two or more rules together possibly by multi-selecting the target rules, and right-clicking
or selecting a "Merge" menu option that will then combine the rules together. Lists (applications,
connections, etc.) would be combined, removing duplicates while single options would possibly
be combined by letting each rule in the list over-write the previous rule's options.
There are several notable challenges. First, is the rule that is the combination of these several
rules a new rule, or do we simply update one of the existing rules? For any rules that are
subsequently deleted, if they are actively "in eval" (that is, waiting on an authorization alert),
they can not be deleted. Further, if any of these rules are part of a Magic List, the magic list
rules themselves are invalidated, as they lose their connection with the main rule.
[Wildcard Support for DNS Names]
Add wildcard support for DNS names in rules. Pretty much does what you would expect. This would
probably be limited to simple, "downward" wildcards, that is,
*.apple.com and not
www.*.com. Maybe later.
DNS names are resolved and cached long before they're needed; adding wildcard support would make
that impossible for connection entries that include wildcarded host names. As long as TrueDns was
functioning properly, it shouldn't be an issue though.
Would also need to prevent wildcard support for GlowWorm FW Lite users.