Conference noted::hackers_v1

IS SIMPLE - its called an ALTERNATIVE AUTHORIZE FILE.

/Bevin

<FLAMETHROWER ON!!!!!>

 ...and not against the people who feel the need to break in, under, 
and around computer security!

 I've had it up to clean past my Keister with system managers that 
don't manage and system operators that don't operate!

 We don't have that situation here on PNEUMA and PSYCHE...to my
knowledge, there is always someone around or available that can get
into the system if it is necessary.  But I often get calls from
frustrated users on other machines with exactly that question: how can
I get into the computer when there's no one around with privileges? 

 In my book, there are explicit and implict privileges.  If privileges 
are reserved to the System Manager, then that means THE SYSTEM MANAGER 
IS RESPONSIBLE FOR THOSE OPERATIONS.  I am SICK and TIRED of SM's that 
refuse to pass out privileges and then refuse to do those opertions 
that require privileges!!!

 Once in a while, someone won't be available--that's normal.  But in 
the past I've had to deal with systems where printouts were locked 
away, and getting a tape on a tape drive required an act of God.  In 
such situations I tend to go after the manager--and the system--with a 
bludgeon.  It's time we started telling certain System Managers what 
the word "Manage" means.

Just to reiterate the original problem:

1)	I had permission to get in (The request was from senior 
	management in that company).
2)	No one with a privileged account was available.
3)	I had access to the computer room.
4)	I could not do a reboot so conversational boots were 
	out.

Points 2 through 4 are valid for several computer systems and 
with special regard to reply .2 why do staff with privilege 
work 9 to 5?

The situation encourages hacking because in the end it is the 
only way to get any work done. Whilst someone directly involved 
in system security should be hacking their way in - it is a 
waste of my time to do so! It also encourages the leaving of 
trap-doors through which hostile hackers can enter.

One interesting system proposed at the Fall '83 Decus US 
Symposium was a privilege request program. That is a number of 
programmers had the ability to call a privilege enhancement 
utility for which they had to give a justification and then 
creates a log entry, e.g.

22-AUG-1984 8:20, ROYCE::KENNEDY,OPER,Need to restart print queue

Effectively this is a SETPRV with a reason and a log entry (the 
latter is in V4, I believe). I realise this method has it's 
shortcomings, but surely it is a good idea in an engineering 
environment.

SET /FLAME=OFF

Hugh.

	Didn't anyone try getting more privileges and THEN getting rid of a 
log entry? Sounds too simple to be even interesting...

					- Victor -

Re: previous reply

If the file concerned is being held open by the logger process for write
without sharing, the file can't be accessed without killing the logger.
Naturally the logger rats on whoever restarted it to make forgery more
difficult.

The system suggested was not intended for storing say the complete CIA
payroll or other secure applications. It is intended more for the type
of situation most of us work in e.g. mostly development/support.

VMS V4 is supposed to implement some kind of tamper proofing for the
security log. That is, a specific privilege is needed to access it.

P.S.	I can't even gripe to my system manager now. He has run out of
	disk quota which MAIL objects to. He, of course, does not notice
	'cos he runs with privileges!

Hugh.

I have know several cases where people did illegal things which they knew
were being logged, and then they would corrupt the entire disk (and crash
the system) in order to cover their tracks. These were cases where the hacker
was on the staff, but was doing work that was not quite in their job
description.

The solution I recommended in one case (as consulting) was that the entire
staff be informed that logging would be increased, and there were certain rules
added about privileged users not looking at other user's stuff, etc. (since
the hackers in this case were privileged!). We thus implemented a 'ring'
security policy, where privileged users could only use programs which had
been 'certified' (ie. from sources to not have trojan horses), and other
such things. They also were informed that everything a user did while using
their privileged account would be logged to a disk file.

As with any security system, the trick is to do something 'extra' beyond what
the hackers know you are doing. In this case, not only was all privileged
sessions being logged, but all TYPE-IN by privileged users was being printed
on a LA120 locked in a closet. If ever there was a system problem (ie hack),
the disk log would be compared with the printed log to make sure it had
not been molested to cover tracks.

Even if the hacker knew about the LA120, the system was still fairly safe
since it is quite difficult to get an LA120 to do reverse scrolling to erase
what has been printed. Since this situation related to a financial institution,
the preference was to catch the person (ie. keep the La120 secret), but
in any case, prevention is often all that is needed.

Another case of doing something extra, is what Dartmouth did with their
time-sharing system back when Kemeny was inventing the Basic Language (or
shortly thereafter). Their trick was that if you entered a password incorrectly
twice, it would keep letting you try to login, but would always say 'invalid
password' even if you got it right. Since hackers didn't realize that
the system wasn't paying attention to their password attempts, they would
often miss out by thinking that they had exhausted the passwords they could
think of, when actually it would work if they simply dialed up and tried again.

Of course, in those days, instead of having microcomputers doing the multiple
'exhaust all possible password' shotgun technique of breaking on, we had to
use paper tape readers on our ASR-33s (at 10 CPS). Even at 10CPS, though,
many systems were quite attainable (it would just go overnite with a home-grown
papertape feeder).  

The point in these messages (I've forgotten what I'm replying to) is that
a little bit of 'extra' (secret) security is often a good way to thwart
a breach of security.

	Actually, to address the original problem, all you need to do is
	know the PID of your process, and have access to a console. What
	you do, is get the index into the PCB vector. This is the lower
	four characters of the PID. Take the number and multiply by 4, 
	and add it to the value of SCH$GL_PCBVEC. Now you have the address
	of your PCB. By placing FFFFFFFF FFFFFFFF in the correct quad
	slot in the PCB, you have given yourself all the privs you need.
	
	I believe the offset from the start of the PCB entry is
	PCB$L_AUTHPRIV. The only catch is that this only works on 11/780's 
	and up, as a ^P on the console for an 11/750 will implicitly halt
	the processor and you can only reboot. This can additionally be
	performed on an 11/730.

							Nestor

	P.S. That is how the program is done to give others privs.
	

You can type the letter 'C' for 'CONTINUE' on an 11/750 and proceed on 
your merry way.  Just tell the users you had a CPU intensive job 
running for a moment to explain the lapse in response time.

tom p

    (years later)
    
>If the file concerned is being held open by the logger process for write
>without sharing, the file can't be accessed without killing the logger.
    
    Ho, hum.  Whatever happened to hacking the file ID out of the window
    control block structures, going to the index file, and playing with
    the mapping pointers?  Or, if the log output is being buffered (a
    bad idea for security-related logging - a crash might lose that
    data for you, which would tell you who crashed it ;-), you should
    definitely hack into the logger process' P1 space and frob the RMS
    buffers.  A truly moby hack would combine both approaches.
    
    #ken "Change Mode" Coar	:-)}
    
    P.S.  CMKRNL just happens to be my license plate number..  ;-)}