Re: Need for security model

On Sun, Dec 07, 2003 at 12:48:36AM +0800, Low Zhen Lin quoted a spec:
> ~    * Authentication
> ~          o Server authentication: Clients must be able to verify that
> ~            they are communicating with a valid server.
> ~          o Client authentication: Servers must be able to verify that
> ~            clients are valid.
> ~          o User authentication: There must be a way to verify that
> ~            user is who he claims to be.
> ~          o Authorization: What level of user rights are granted after
> ~            authentication. Is user or client granted only the right
> ~            to browse, or to carry out installs? Is user or client
> ~            permitted to make operations that builds new toolchains or
> ~            are they constrained to using the services that are
> ~            already offered only?

What is Xeta?  Is it a build manager?  Is it a download manager?
Is it a file transfer protocol?  Is it a web server?  Is it is an
rsync server?  Is it all of the above? :-)

I still don't understand why Authentication is part of Xeta (probably
because I don't understand completely what Xeta is trying to be).
There are other protocols and means of doing this, but if Xeta is
integrating this for ease of use, I suppose that could be handy.

> ~    * Auditing: What happened, who caused it to happen and when did it
> ~      happen. Failed transaction attempts must also be recorded.

Sounds good, from a server point of view.

> ~    * Access control: Control of permissions to resources. Does user
> ~      or client have access to XBuild A, but not to XBuild B? Does
> ~      user or client have access to using toolchain A, but not
> ~      toolchain B?

Xeta is going to control this?  How?  With kernel help?

For example, suppose I have access to the C compiler toolchain, but not
the java compiler toolchain.  Will I not be able to run the java compiler
on the machine even from the command line?  And if I can, how will
Xeta stop me from using the java toolchain?

Am I misunderstanding, yet again? :-)

> ~    * Integrity: Verify that data has not been modified in transit
> ~      over network.

This is the #1 feature that I'm looking for and hoping for from Xeta
and Zynot in general.  This is regarded as so unimportant by so many
people that I find it shocking, and I'm glad Zynot is making it a
primary design goal.

I would prefer this integrity to rely on as few points of failure as
possible: i.e. something like a developer-signed XBuild, and not
something that ever relies on the security of the server or mirrors
holding the data.

> ~    * Confidentiality: Protect data in transit against eavesdropping.

Sounds good, but seems to me to be more of a fluff feature, for what
I imagine Xeta being used for.  Does it matter if someone is able
to sniff the wire and find out I installed the latest binutils?
I'm willing to be convinced that it does matter, but so far can't
class it as a critical need.


> ~    * Non-repudiation: Make sure that no client, server or user is
> ~      able to deny a transaction after it happened.
> 
> 
> Some thoughts about single sign-on and trust between Xeta units would
> be welcome. A security boundary could be established, and effectively
> it could work, not only for Xeta, but the others tools that will
> complement it in the  future. All nodes within a Zynot security
> boundary will most likely have Xeta or some Xeta component installed.
> How can we leverage this to extend the management capabilities of our
> tools?

Is discussion of Xeta and Zynot development happening outside the mailing
lists, perhaps in irc?  Are there logs of irc meetings that can be
read somewhere?  Couldn't find it with a cursory glance at the website...

- Chris