[colug-432] best ID function

[Rick Troth]

For expanding on "goodness", see attached, which is based on feedback
I've heard so far.

THANK YOU, friends, for the excellent discussion and input.  Seems
maybe it was a more interesting topic than I expected.

I have memories of getent() being complicated.  The now common higher
level routines do the job well enough.  If anyone has suggestions for
the attached implementation, lemme know.

> I suspect your are writing code with the assumption of a
> network environment, for a presentation in June you may be
> doing ...

Indeed, yes.
I hope to present shared filesystems (shared disk) again at the VM and
Linux Workshop.  This time around, I expect to demonstrate cloning of
a shared disk system using one of our products.  Would be nice if
those in attendance could then sign on ... just to go the last mile in
terms of actual viability.

Some back story:
This is mainframe stuff.  Mainframe Linux is 100% Linux, and MF HW
does have an ASCII mode console interface.  But a lot of the
traditional tools fall back into ye olde EBCDIC flavor.  (Nationwiders
on the list may be familiar.  Others too.)  If you're on z/VM, there
is a pseudo network called IUCV.  On Linux and on CMS, there is a
sockets interface AF_IUCV (compare to AF_INET and AF_INET6).  Using
this, one of the developers at IBM created an "IUCV Console Service",
a client and a server.

SO ... customers SSH into a console server and then use IUCV to hit
other Linuxen.  Works.

Here, I don't need to code sockets.  I will simply exec() a client
already written.

What I am writing is a jail so that the user you sign on as is captive
and runs 'iucvconn $THATID $TERMID'.  Demo customer signs on using a
name that matches the clone.  (In English, the Linux username matches
the name of the virtual machine you're going to use.)










On Mon, May 13, 2013 at 2:06 PM, R P Herrold <herrold at owlriver.com> wrote:
> On Mon, 13 May 2013, Rick Troth wrote:
>
> Some further definition of the 'goodness function' are needed
> to understand what 'best' means here ... Here is an entrant
> for 'best' as to the second example, It is one I discussed in
> a call last week, which PMman supports well.  I need to write
> a blog post ...
>
>> In this case, I need the username, not the UID.
>
> getent if one has an ability to query up into the parent, but
> in a chroot ('I'm writing a jail ...') environment, I am not
> clear that this works portably
>
> I suspect your are writing code with the assumption of a
> network environment, for a presentation in June you may be
> doing ...
>
> As such assuming network access, (and having the nice property
> of having 'zero forward knowledge' being exposed beyond the
> value of a 'general case' payload, here: userid [1]), a salt,
> a shared secret, and a unique per application set of keying,
> of a symmetrically encoded value placed into DNS through a DNS
> management API, It is pretty easy to write (basically being an
> implemention grafting a DHT facility [2] on top of DNS)
>
> Meta-code follows.  Plaintext DNS transfers are fine across
> untrusted networks, as the strength is needed only at the
> (assumedly protected) endpoints
>
> Only a few minimal transactions need be supported outside of
> the fairly trivial crypto transforms (all transforms shown in
> the worked example below):
>         write
>         read
>         clear
>
> The calling side either re-uses a salt from an agreed
> location, or a pre-known one, or if it knows that it is a one
> time use, could place one at a temporary UUID name 'A' with
> a 'write' transaction
>
> The called and calling side each know a shared secret (similar
> to Radius' approach), and here, a 'passphrase' as well
>
> The calling side places an encrypted value of the plaintext to
> be transferred (here, the username) at either an agreed
> location, or if it knows that it is a one time use, could
> place it at a temporary UUID name 'B' with a 'write'
> transaction
>
> The calling side hands the the value of B (and optionally A)
> to the called side.  If the transaction needs to cross an
> unprotected network, gpg clearsigning the transaction comes to
> mind.  Not relevant in a chrooted environment
>
> The called side uses B (and optionally A), and the shared
> secret to product the plaintext back with a 'read'
> transaction
>
> Optionally the called side, or the passage of time, or the
> calling party when it gets a return code, or whatever can
> 'wipe' the transient data with 'clear' transactions toward B
> and A
>
> Logging happens on the DNS server, and as otherwise desired.
> 'False flag' MitM pollution is detectable there.  The DNS
> server lacks other sufficient information beyond the effective
> IPs of its querying counterparties, such that it has no way to
> decode (decrypt) the transferred payload data; as it lacks
> both the shared secret, and the passphrase
>
> This implementation does not contain a MAC and is subject to
> replay attacks -- thus the wipe -- but that is out of scope
> here and as noted trivially solved.  A and B need not be
> published in the same DNS domains, of course, to taste as to
> privacy
>
> --
> end
> ==================================
>   .-- -... ---.. ... -.- -.--
> Copyright (C) 2013 R P Herrold
>        herrold at owlriver.com
>     My words are not deathless prose,
>        but they are mine.
>
>
> [1] http://en.wikipedia.org/wiki/Zero-knowledge_proof
> [2] http://en.wikipedia.org/wiki/Distributed_hash_table
>
>
> Worked example:
>
> 1. Retrieve the salt from:
>         dig -t txt salt.owlriver.net
>
> [herrold at centos-6 ~]$ dig -t txt salt.owlriver.net | grep TXT
> ;salt.owlriver.net.             IN      TXT
> salt.owlriver.net.      296     IN      TXT     "0a07"
>
> and which was produced:
>
> [herrold at centos-6 ~]$ openssl rand -hex 2
>         0a07
>
>
> 2. The client specific shared secret is:
>         deadbeef
> and the shared passphrase is:
>         asdf
>
>
> 3. The plain text was at:
>         dig -t txt colug1.owlriver.net
>
> 4. The cipher text is at:
>         dig -t txt colug2.owlriver.net
>
> [herrold at centos-6 ~]$    dig -t txt colug1.owlriver.net | grep TXT
> ;colug1.owlriver.net.           IN      TXT
> colug1.owlriver.net.    295     IN      TXT     "Hello Colug"
> [herrold at centos-6 ~]$    dig -t txt colug2.owlriver.net | grep TXT
> ;colug2.owlriver.net.           IN      TXT
> colug2.owlriver.net.    300     IN      TXT
>         "U2FsdGVkX18KB96tvu8AAF8SnDkSeyjhd4stUIrWSmA="
> [herrold at centos-6 ~]$
>
>
> 5. The transforms (here plain old DES ... dial up to taste)
> are:
>
> [herrold at centos-6 ~]$ echo "Hello Colug" | openssl enc -e -des
>         -S '0a07deadbeef' -a -pass pass:asdf
> U2FsdGVkX18KB96tvu8AAF8SnDkSeyjhd4stUIrWSmA=
> [herrold at centos-6 ~]$ echo
>         "U2FsdGVkX18KB96tvu8AAF8SnDkSeyjhd4stUIrWSmA=" | openssl
>         enc -d -des -S '0a07deadbeef' -a -pass pass:asdf
> Hello Colug
> _______________________________________________
> colug-432 mailing list
> colug-432 at colug.net
> http://lists.colug.net/mailman/listinfo/colug-432



-- 
-- R;   <><
-------------- next part --------------
A non-text attachment was scrubbed...
Name: consjail.c
Type: text/x-csrc
Size: 298 bytes
Desc: not available
Url : http://lists.colug.net/pipermail/colug-432/attachments/20130513/73126b20/attachment-0001.bin