nanogui: Access control
Subject:
Re: Access control
From:
Joe deBlaquiere ####@####.####
Date:
16 Dec 2000 19:30:04 -0000
Message-Id: <3A3BC3EB.7080306@redhat.com>
Do you even have to change the interface from a unix domain socket? I
would think you could just have 'nxsshd' open the unix socket.
Andrew Hannam wrote:
> 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: ####@####.####
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
--
Joe deBlaquiere
Red Hat, Inc.
307 Wynn Drive
Huntsville AL, 35805
voice : (256)-704-9200
fax : (256)-837-3839
