Re: Need for security model

On Tuesday, December 9, 2003, at 04:11  AM, Chris Frey wrote:

> 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? :-)

Much of that. It is the build manager, download manager, package 
manager among some other things. It will be distributable, meaning, you 
can run the components on different computers, but it will be able to 
form one coherent whole.

> 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.

Obviously, when doing something as crucial as system management, no 
man-in-the-middle attacks can be allowed. In fact, no attacks can be 
allowed. The fact that it happens over the network makes it open to 
attacks. Authentication is needed to ensure that the services are being 
used by an authorised person... To ensure that the data is authentic 
and has not been tampered with... To ensure that you are in fact 
speaking to the correct node and service.

>> ~    * 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?

Since Xeta is based on a multi-tiered model, what the client can do can 
and must be controlled server-side. Even clients on the local computer 
will have to communicate via IPC of sorts. Therefore... It will not be 
necessary to invoke the client as root... But, the server is running as 
root. Thus, the client cannot be trusted - some form of authentication 
and access control must be implemented.

Perhaps with the help of PAM.

> 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?

You already have the root password... who needs Xeta?

>> ~    * 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.

MD5sums are present in Gentoo - this is a necessary feature if we are 
to claim superiority to Portage. However... MD5sums are easy to 
recompute.... Which is why we are also planning to make use of 
cryptographic signatures.

> 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.

As few? I'd rather install integrity checks at every point possible.

>
>> ~    * 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.

No... But they could use the information that you're about to start a 
KDE compile on the webserver and launch a DDOS attack. You're right 
that this is not a critical need... But what is one to do when the PHB 
says, nothing leaks out of the computer network?

>> ~    * 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...

Mostly IRC. Realtime discussion is good. I can provide logs, but since 
my personal computer failed, I can't get to them. Obviously, they are 
also gaps from the time when my IRC client was not active and I was not 
able to restart it.

If you're wondering about the integrity of this message... I cannot 
cryptographically sign it - owing to the fact that I am not sending 
this from my personal computer.

Please post all future followups to [email protected] - only the 
initial message goes out to both. Duplication is bad.