🚀 go-pugleaf

mikec@mundil.cs.mu.OZ.AU (Michael CIAVARELLA) writes:

>Hi all,

>I have a (hypothetical) situation which I'd appreciate
>some comment on.  I've tried to be as exact as possible,
>but if you want any clarification just mail away.

>Machines XX and YY belong to different departments - each
>machine's maintenance, support and associated staff being  
>paid for by the relevant department.  Whilst each machine
>is run separately, they do have some users in common.  
>There are no shared filesystems between XX and YY though
>they are on the same network, and it is possible to 
>login to each machine from the other.  

>Let's say A is a non-administrative user who has an acount
>on both XX and YY.  The administration on XX has specifically
>forbade the use of program I on their machine, either directly
>or while remote-logged in to program YY.  There is no such
>restriction on machine YY.  So, user A logs into
>host YY, compiles up program I, and leaves the binary in his
>account on YY.  The next day, A logs on to YY to use his
>newly-installed program, only to find that the binary has
>been deleted during the night.

>So, person A questions the administrator on YY as to why his 
>binary was deleted.  YY's admin is surprised at the question
>because he certainly didn't do it.  In fact, on checking
>through the system logs, it looks like A deleted his own file.
>A knows he didn't do it either, and that the chances of his
>password being cracked are infinitesimal, since he only changed
>it yesterday, and it was a reasonable password.

>He does, however, have a .rhosts entry on YY allowing him to 
>login from XX, and indeed, the system logs show that this 
>took place last night. However again, A didn't perform this login.
>In fact, he'd changed his password on machine XX yesterday, 
>and on checking through the system logs on XX which just 
>happen to be publicly readable, the only person using XX 
>at the time of the remote login, was XX's system administrator.

>Now, all questions of technical security aside, the evidence
>seems to point to the admin on XX impersonating A and removing 
>the file belonging to A.

>If this is in fact the case, then:
>	1)	What are the legal implications (if any)
>		of the XX admin's actions?
Probably a breach of some Cth legislation (Criminal) concerning communications.
This is pretty precarious and given the prosecution's competence not likely to
get to court.
Possibly an offence under the Victorian forgery provisions but again I suspect
judges will be quite lenient on sys.ops. who have authority to do an awful lot
on the system. THere may be informal understandings about mutual management of
resources. (These are pretty normal at Melbourne)

>	2)	If A logs in to YY from XX and uses his
>		program, does this give the XX admin the
>		right to act as he did?

If YY sysop deletes the binaries (or denies access by a group) there is a
clear prohibition to that group using that service on that machine.
Given the Victorian provision on computer trespass (s.9 Computer Crimes Act)
A is in a lot of hot water if A goes to court so I suggest that A should cut
their losses. :-) 1/2

If XX sys.op. is employed to maintain the system and the use on the machine
is provided for course purposes then the sysop has every right to ensure that
the system operates the way he authorizes it. If there is some implied
authority but no other way for him to remove the file then why not?
>	3)	What would you do in the XX admin's place?
Alert the YY admin of the breach and suggest they delete the binary and suspend
the students account indefinitely.
>	4)	What would you do in A's place?
I wouldn't be in A's place. I'm not that stupid.
>	5)	What would you do in the YY admin's place?
Delete the binary and suspend the student's account pending an explanation.
After making the student sweaty a little I'd restore the account. If it
happened again I'd refer the student to the Head of Department after
suspending the account recomending disciplinary action or prosecution.

>If the admin didn't in fact "do it" then the question remains:
>		"whodunnit?" ;-)
Unix is not secure. There are a lot of backdoors.

# This is not legal advice. If you intend to act on these statements you should
obtain appropriate legal advice from a qualified solicitor. I am not
responsible for damages arising from reliance on these  statements.


-- 
-----------------------------------------------------------------------------
Tim Arnold        | Law/Science (Computer Science)   |  simul iustus
tja@cs.mu.oz.AU   | The University of Melbourne      |  et peccator
=============================================================================