Suggestions (~wishlist)

[Lee Winter]

On Thu, Sep 17, 2009 at 10:15 PM, Teddy Hogeborn <teddy at fukt.bsnet.se> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Lee Winter <lee.j.i.winter at gmail.com> writes:
>
>> Mandos Suggestions
>>
>> 1.  Alternative plugin to allow operator to provide host-specific
>>     boot password on removable media such as floppy, CD, or USB.
>>     The idea is that a user could construct a "master boot key"
>>     containing all of his boot keys and just plug it in during boot
>
> As I understand it, this already exists outside of Mandos; See the
> documentation about 'The "passdev" keyscript' in
> "/usr/share/doc/cryptsetup/README.initramfs.gz".

It does, but it is exclusive.  I.e., cryptsetup does either manual
entry or a passdev entry.  I was hoping to build upon the
multi-channel nature of mandos to allow the operator to either type in
the password or plug in the device rather than be forced to conform to
a preset choice.

It's just a wishlist item.

>
> I suppose we could write a Mandos plugin which in turn runs "passdev",
> but I don't really see much point to it?  If this is what someone
> wanted, wouldn't they just use "passdev" *instead* of Mandos?

No, because plugging in the device is an alternative to mandos not a
replacement.  Just as manually typing in a password is an alternative
rather than a replacement for mandos.

Operationally the passdev is a replacement for manually typing in a password.

>> 2.  The only feature I need to overcome the limitations of the
>>     heartbeat poll is a way to disable the mandos server.  if that
>>     feature is available then the clients can be thoroughly
>>     secured.  But that should be part of the UI for the server.
>
> I agree - this is already an item in the TODO file.
>
>>     Below is that I suggest that UI should support:
>>
>> A. Notification -- when a client requests a key
>>         primary: execute something external
>>                 typically a user-defined program or script
>>                 should provide some details such as client's host
>>                 name as parameter
>
> Yes, this was also what I thought at first, but then I realized that
> providing notifications via D-Bus was cleaner and more flexible.  When
> you think about it, any and all events in a server is a possible place
> to add such "execute some program" hooks, and this either becomes
> unwieldly or one would have to make a large number of arbitrary
> judgment calls on what events would be interesting or useful enough to
> warrant a hook.

Well basically it is your call, but I disagree.  D-Bus is clearly much
more powerful.  But that power comes at a very high cost.  Rather than
providing any old executable a client of the mandos notification
mechanism now has to be a fairly serious program in its own right.

It was my intention that there be only one notification -- client
asking for key.  If you have other events to report then the
shell/exec/spawn/system() approach is not as useful.

> So, I have no plans to implement this, since any program wanting to do
> this will be able to just hook itself up to the D-Bus system bus and
> wait for the Mandos server to send an appropriate signal (with useful
> information attached).

I have not looked at D-Bus adapters yet, so something like what I
envision may already exist.  But it not you may decide to add it as a
default/example D-Bus client.

If the primary notification mechanism is D-Bus I predict substantial
demand for a D-Bus client that would just provide a
shell/exec/spawn/system() type of capability for a main event, which
is a key request.

>
>>         secondary:
>>                 write status to a file, such as a log
>
> The server already sends log messages to syslog(3); it should be
> possible to configure the syslog daemon to send the log anywhere.  I
> think this is the proper division of abstractions in this case.  Also,
> for any event warranting a log message, a D-Bus signal will be sent,
> too.
>
>>                 change the contents of a status-oriented web page
>>                 (external poll)
>>                 send an email
>>                         provide details in body of message
>
> As above, this can be implemented using programs listening for the
> server's D-Bus events.  I do not plan to write such programs myself at
> this time - I'm looking at other features (such as the D-Bus interface
> itself) at the moment.  However, contributions are always very
> welcome!

I was only enumerating alternatives that might be more palatable than
launching an executable.  They aren't as good.

>
>> B.  Operating Modes (for the server and for each client)
>>         1. Just do it -- as current operation is defined
>>         2. Wait for permission*, impatiently optimistic (affirmative
>>            timeout = no operator action -> give out key)
>
> Good idea; I've added it to the TODO file.
>
>>         3. Wait for permission*, patiently (no timeout = wait
>>            forever)
>
> Hmm, I had thought about this, but I see now that it's not in the TODO
> file; I've now added it.  Thanks!
>
>>         4. Ask permission*, impatiently pessimist (negative timeout
>>            = no operator action -> disable client)
>
> I don't see the point of this - couldn't the client just be disabled,
> and the operator could then enable it when desired?

This exists to handle a specific issue.  The timeout exists because we
expect to support a Man in the Loop (MitL) operation, but the operator
is not attending to the machines (except virtually).  So the
expectation is that an operator would receive notice of a client
requesting a key, do whatever checking required a human's judgement,
and then respond within the timeout.  If there is no response within
the timeout then the premise that there is a MitL is shown to be false
and the system should go limp.

The intention of the optimistic timeout is that an operator may want
to check for reasons to _abort_ the boot process, particulary in the
case of an expected reboot, so the default is to provide the key.  The
intention of the pessimistic timeout is that an operator may want to
allow an otherwise unanticipated key request, and if they do not then
the request is denied and a physical intervention at the console of
the client is called for.

>  But then the
> client wouldn't ask that server again until it re-announces itself, so
> should the server do that?  I don't know what the best way to
> implement this is, so I'll decide that later, but I agree that the
> basic functionality should be there.

I think you could consider it an issue of completeness.

>
>>         5. Don't do it -- disabled
>
> Yes, already in the TODO file.
>
>>         A client's effective mode is the maximum of the client's
>>         assigned mode and the server's (global) mode.
>
> Wait a minute.  My comments above are about the *server* modes.  What
> use would any of the modes above be, as applied to the *client*?

I may not have described the modes clearly enough.  All of the mode
variables are on the server.  But there are individual modes for each
client and an overall mode for the entire server.  I could have
labeled them local-to-the-client and global-to-the-server, but I use
ambiguous shorthand names.  Sorry.

The server maintains a mode variable for each client so each can be in
a separate state (could be implemented the other way around with five
lists of clients corresponding to the five modes, but you have to
check for duplicate entries, etc. -- too much overhead).  The server
also maintains a single global mode variable (like a DefCon).  When
any particular client asks for a key the servers response is guided by
the maximum of the mode assigned to the client and the server's global
mode.  That's why the modes are listed in order of increasing
strictness.

> Let's enumerate:

None of the modes should affect the state of the client machineor even
be accessible from the client machine.  Only the server's response to
each client should be affected.

[snip]

>> C.  Control panel
>>         Access
>>                 accept only secured connections
>>                 option to limit connections to only designated FQDN
>>                 or IP address.
>
> My current thought is to punt on this and provide a D-Bus interface on
> the server and some command-line tools which uses it

OK.

> (D-Bus is
> accessible on the local host only, and the Mandos server's D-Bus
> interface will require root privileges to access).  If someone wants
> to write a web interface, they'll have to decide on a security model
> themselves - it feels to me like what people would want is too diverse
> for me to just arbitrarily pick something.  I'm thinking that someone
> will eventually write a web interface and contribute it, and we'll
> then be happy to include it.
>
>>         Actions
>>                 allow changes to operating modes (described above)
>>                 per client and/or globally
>
> Yes, I agree.
>
>>                 supply or deny permission for pending client's
>>                 requests for keys
>
> Yes.
>
>> D.  Stability
>>         Rebooting the client should not affect its assigned
>>         operating mode
>
> Where in the world would the client save this information?  There is
> nowhere to write anything - the client runs in the initial RAM disk
> environment; everything is ephemeral.

Again I should have been more specific.  Try this: "rebooting a client
should have no effect upon the operating mode that the server has
associated with that client".  I.e., I am sugesting that no action of
the client should alter anything on the server.

>
>>         Rebooting the server should not change anything about how
>>         clients are handled.
>
> Yes, of course - this was always the intention of the idea of the
> server having a persistent state.  Hmm, I see that this is not in the
> TODO file; I've now added it.

Good.

I hope this clarifies the confusing parts of my suggestions.

-- Lee