Access Control Designer is a universal modular tool for visually designing access control policies. The user of this system depicts requirements for the designed security policy in a graphical notation based on a generally accepted security model. The tool will then generate a configuration of security mechanisms, which will be used for the implementation of the security policy. Modularity of the tool will allow users to design security policies for a lot of various environments - systems needed to have access controlled. A pluggable module API allows third-party programmers to provide ACD modules for systems and so allow users to use ACD for designing access control policies for the systems.
cryptoloop is obsolete
Cryptoloop is obsolete, buggy and has security weankesses. You should use dm_crypt instead.
Though I'm still quite skeptical about a real need for such a system, I'm going to add a few points to the discussion. And maybe once the succcess of the project will beat my skepticism :)
The functional and architectual model (here and on the project website) look good to me. I just miss a data-design.
What will be the structure of data flowing through the system? You only speak about text fields, integers and such non-structured entities. But in real life and in real configuration schemes, the information in configuration files is more structured.
Look at apache for example. The configuration options like DocumentRoot or ErrorLog can be specified for the whole server, for one virtual server, for one directory etc. Parameters in subdirectories are inherited from their parent directories. Some configuretion options are not allowed or have no meaning for directories and can only be specified globally. Values of some configuration options include other configuration options... I guess you see the point.
Another look at the data: I propose the low-level data entity should be a chunk of a diff file to the orignal configuration file. This approach has proved to fit for the need of editing files by various players - the user editing the configuration file directly, your system or maybe even some other configuration system used on the machine. The main pros - consistency (it's harder to damage a file with a diff than by rewriting it from scratch), auditing (when you log a diff-file, then you can easily see who did what and why).
And by precisely defining data-structure, you can precisely define interfaces. A great pro for a modular system like yours.
Luckily, XML is very flexible for use with structured data, so there should be no problem with the implementation.
Hope this brings something for you,