nanogui: Access control
Subject:
Re: Access control
From:
"Andrew Hannam" ####@####.####
Date:
14 Dec 2000 13:09:01 -0000
Message-Id: <008b01c065ce$0e2ef280$0104010a@famzon.com.au>
As a crypto expert - the administrative (and potential size) issues are
making this look a bigger job than should be undertaken for a tiny GUI such
as Microwindows.
A suggestion:
Most things that can be done inside an application can also be done by
wrapping it.
Why not convert Microwindows unix domain socket to a real socket and
then use a separate tool/program/utility to wrap and protect the connection.
That way the microwindows core code is not burdened with something as
off-topic as the crypto world and the strength of the final solution can be
controlled by the strength of the separate wrapper that is used.
This is similar to using for example an SSH tunnel to protect an otherwise
insecure service.
The one requirement I would suggest is that the network listener within
microwindows should be able to specify the listen address.
For example ...
Listen-on=127.0.0.1:1500
Talk-to=127.0.0.1:3000-3500
Would enable you to set up a secure system where your security wrapper
talked to microwindows on port 1500 where the security wrapper ran on the
same machine using ports 3000 - 3500 when talking to microwindows.
Listen-on=*:1500
Talk-to=*:*
Would conversely talk to anyone making a connection to microwindows on port
1500.
Now you have the best of all worlds,
a) A very simple solution for microwindows
b) Non-pollution of the intent and code base of microwindows
c) Customisable level of security depending on the situational
requirements
d) Potential to use already available and tested security solutions.
Hope this helps,
----- Original Message -----
From: "Alex Holden" ####@####.####
To: ####@####.####
Sent: Thursday, December 14, 2000 9:53 PM
Subject: Re: Access control
> On Thu, 14 Dec 2000, Alan Cox wrote:
> > > So you're saying that all the existing protocols which use hashed or
> > > encrypted authentication but not actual session encryption (kerberos,
> > > etc.) are no better than ones which use plaintext authentication?
> > Unless they use the hash to protect all the data - pretty much.
>
> Okay, so it looks like encryption of the session data is a must for any
> real level of security. How about this, we have a two level system:
>
> * No encryption, plaintext passwords using the ordinary Unix password
> mechanism (assumes the network is fully secure).
> * Full encryption of both authentication and session.
>
> However, as to my previous idea of providing the encryption via ssh:
> [alex@hyperspace alex]$ ls -l /usr/sbin/sshd
> -rwxr-xr-x 1 root root 622900 Nov 8 15:56 /usr/sbin/sshd
> [alex@hyperspace alex]$ ls -l /usr/bin/ssh
> -rws--x--x 1 root root 663300 Nov 8 15:56 /usr/bin/ssh
>
> Those are stripped binaries, and they also depend on several other
> libaries.
>
> So I'm currently thinking of implementing an encryption layer based on TEA
> (Tiny Encryption Algorithm). TEA is an incredibly small (748 bytes on
> 386), very fast (faster than IDEA), very strong (much stronger than DES)
> 128 bit private key cypher which isn't patented and has a completely
> public domain C reference implementation available.
> See http://vader.brad.ac.uk/tea/tea.shtml for more information.
>
> By the way, I realise that if we put this in the main distribution itself,
> it would prevent people in countries with draconian encryption import
> regulations (like France) from downloading it, and might not be exportable
> from the US (I'm not sure what the exact situation with regard to that
> is at the moment) so it'll be available as a seperate archive hosted in
> the UK instead. I assume there are no regulations preventing people from
> downloading software which contains hooks for making use of encryption
> code but not the encryption code itself?
>
> --
> ------- Alex Holden -------
> http://www.linuxhacker.org/
> http://www.robogeeks.org/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
