HDTenEightyP/NetNews huggingface dataset:
From: palmer@Trade_Zone.msfc.nasa.gov (Paul (Cliffy) Palmer)
Subject: Re: They forget rusers, was Re: reasons for
Reply-To: palmer@Trade_Zone.msfc.nasa.gov
Organization: New Technology, Inc.
Date: Sat, 12 Dec 1992 01:04:22 GMT

In article Jyu@avalon.nwc.navy.mil, dejesus@archimedes.nwc.navy.mil (Francisco X DeJesus) writes:
>In article <1992Dec9.173938.8706@nntp.hut.fi> jkp@cs.HUT.FI (Jyrki Kuoppala) writes:
>
>Still, doesn't rusers (and rup, rlogin, rsh, etc) require a hostname? If
>they don't work with IP addresses (they way finger/telnet can) then their
>use is restricted if the machine you are trying to "probe" isn't registered.
>Anyone know of a way around this (other than making a local entry in your
>hosts file)?
>

rusers the program does require a hostname, although the rusers (RPC)
protocol does not.  If you have written an RPC program it is fairly
trivial to rewrite the rusers command to accept IP addresses.  I
suspect that rlogin and rsh have a similar problem, although they are
not RPC programs.  It should just be a simple matter of getting the
source and modifying it to accept IP addresses.

For another approach, some vendor's systems support an environment
variable that can be set to the pathname of a "local" host table.  This
allows users to augment the hostname lookups to include all of their
favorites...

---
Paul (Cliffy) Palmer

Newsgroups: comp.security.misc
From: wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705)
Subject: Re: Security vs usefulness (was Re: reasons for disable fingerd)
Organization: Here, beside the rising tide
Date: Mon, 14 Dec 1992 01:35:54 GMT
	<Byr9qE.24p@dscomsa.desy.de> <1fvngjINN297@iraul1.ira.uka.de>

In article <1fvngjINN297@iraul1.ira.uka.de> s_titz@ira.uka.de (Olaf Titz) writes:
   In article <Byr9qE.24p@dscomsa.desy.de> Hallam@zeus02.desy.de writes:
   >This is my grip against UNIX. You can either have a secure system or you can
   >have a useful system. You can't have both at present.

   My experience shows that this is not a UNIX problem, it is a general
   problem. Even an operating system stuffed with 'security' facilities
   like VMS is likely to stop legitimate use, if you turn on all those things.

The main job of security is to say "NO".  
The main job of Unix is to say "Yes".
The other main job of security is to keep track of who did what to what,
	so that if you decide the system *should* have said no, but didn't,
	you know what got stolen.
The other main job of Unix is not to waste your time with all this detail
	about who did what to what - the normal say to indicate sucess
	is silence.
Yes, there are some conflicts :-)

The main problems with security on Unix, and on many other systems, 
are that sometimes the easiest way to get a job done is loses track of
the identity or privileges of the real user, which takes some work
to fix if you *know* the identity of the real user, 
and that sometimes it's genuinely hard to know who the real user is,
especially across a network where you don't control the other end.
One way to resolve the latter problem is to always trust the user;
another way is to never trust the user; a middle way is to work hard
and try to give you some control about how much trust you have.

The Orange Book takes the don't-trust-them way, and loses capabilities.
Unix falls in the middle way, and sometimes gets it wrong.
MS-DOS knows there is only One User in the Universe, and She can do 
what She wants, so it's perfectly secure in the Great Cloud of Unknowing :-)

(Then of course, there are bugs and misfeatures, and the relative
quantities of these in Unix vs. other OS's is beyond the scope of this note :-)
But it is a lot easier to do security, and everything else,
if your system has a clean model of reality behind its design.
Tacked-on stuff never does as well, and many of the nice tools on Unix
really were afterthoughts.
--
#				Pray for peace;      Bill
# Bill Stewart 908-949-0705 wcs@anchor.att.com AT&T Bell Labs 4M312 Holmdel NJ
# Nov 12 - Anniversary of Indonesian massacre in East Timor, 1991
# Indonesia first invaded in 1975, and about 1/3 of the people have been killed.
Newsgroups: comp.security.misc
From: palmer@Trade_Zone.msfc.nasa.gov (Paul (Cliffy) Palmer)
Subject: Re: Hiding Unix processes?
Reply-To: palmer@Trade_Zone.msfc.nasa.gov
Organization: New Technology, Inc.
Date: Mon, 14 Dec 1992 20:51:08 GMT


>In article <1g42e5INNoac@darkstar.UCSC.EDU>, speth@cats.ucsc.edu (James Gustave) writes:
>
>   Is there a way to mask all of your running processes, similar to what the
> execl command can do for a single process?  I don't really like having
> everyone be able to see what I'm doing all the time.
>   I'm running SunOS Release 4.1.1, and I don't have root privs.

As a normal user, I have never run across a mechanism to do this in a
fool proof manner.

However, on hosts where it was necessary to segregate users, I have
removed the setuid bit from the ps (and pstat) programs, moved them
aside and placed wrappers in their place.  These setuid wrappers would
inspect their arguments and make sure they did not include any requests
to see other user's processes.  Valid requests were then processed by
invoking the original ps or pstat program.

This solution is simple, but less than ideal because some requests are
difficult to verify (requests for processes by process-id or
controlling terminal.)  The best solution was to modify the ps source
code to perform the appropriate checking.

In summary, if you have the assistance of your system administrator,
you have a couple of options.  If not, I would be interested in hearing
anything that you come up with.

----

Paul (Cliffy) Palmer

Xref: sparky comp.security.misc:2260 comp.org.eff.talk:7676 alt.society.civil-liberty:6919
From: jkp@cs.HUT.FI (Jyrki Kuoppala)
Newsgroups: comp.security.misc,comp.org.eff.talk,alt.society.civil-liberty
Subject: Re: CERT's login banner
Date: 15 Dec 92 13:00:27 GMT
Reply-To: jkp@cs.HUT.FI (Jyrki Kuoppala)
Organization: Helsinki University of Technology, Finland

In article <143411@lll-winken.LLNL.GOV>, karyn@cheetah (Karyn Pichnarczyk) writes:
>What about this example:
>
>Joe works for company X.  He is using their computers to calculate
>payroll for a company Y that he owns and is in no way related to
>Company X.  He knows he is "not supposed" to do this because something
>like that is in the policy of the company.  Because of this, he does
>his payroll after normal business hours.
>
>The system admin of company X gets suspicious of some random cracking
>activity on computer systems (unrelated to Joe).  Sysadmin decides
>that since all cracking activity happens after normal business hours,
>and since no users claim to use the computer after hours, keyboard
>monitoring of all after hours users takes place and thus Joe's payroll
>activity is discovered.
>
>Questions for comp.security.misc:
>
>1. Is this invasion of privacy?

If the policy of monitoring is announced, I don't think so.  If it
isn't, it might be - if it's OK to use the computer after hours, it
is, but if it's against company policy to use the computer after hours
then I don't think it's that bad.

>2. What if Joe's business is a random legal business?
>3. What if it's an illegal Drug Ring?

All possessions of companies X, Y and Joe will be instantly forfeited
to the government and all employees will spend life in jail?

Actually, I think 2. is worse since you can easily hire a company to
do payroll for a normal company - with 3. it's understandable that one
wants to hide the business because of the fascist laws.

In both cases, the reasonable thing to do in my opinion would be for
company X to give Joe a severe warning or perhaps sack him for
violating a company policy by using equipment for non-company use.
The fascist laws probably require the company X to report Joe to the
authorities in 3., however, or the company itself will get in trouble.
Or if it's 3. and the profits are good, perhaps ask Joe to buy some
new and better computers for company X and let Joe have the old ones
and say he can keep his job if the use of company resources will end ;-)

>4. Do you think CERT's banner might make a difference in the legal
>hassles?

No idea, but the Justice Dept. seems to think it will, and I guess
they have some expertise/influence on the topic.

//Jyrki
From: s_titz@ira.uka.de (Olaf Titz)
Newsgroups: comp.security.misc
Subject: Re: Security vs usefulness (was Re: reasons for disable fingerd)
Date: 14 Dec 1992 11:47:47 GMT
Organization: Fachschaft math/inf, Uni Karlsruhe, FRG
NNTP-Posting-Host: irau31.ira.uka.de

In article <WCS.92Dec13203554@rainier.ATT.COM> wcs@anchor.ho.att.com (Bill Stewart +1-908-949-0705) writes:
>
>The main job of security is to say "NO".  
>The main job of Unix is to say "Yes".

O.K., you agree in this point: The main job of Unix is to get the
user's work done.
The main job of security is to stop the user from getting his work
done.

=> "Security" as defined such belongs on the crap heap and not in
computers that are to be USED, imho.

>The other main job of security is to keep track of who did what to what,

To spy on the users.

>	so that if you decide the system *should* have said no, but didn't,
>	you know what got stolen.

But then it is too late and you have caught a bug, perhaps, but not
the intruder, according to your 'security' definition.

(And, mentioning that word reminds me of the following: The sometimes
arbitrary redefinition of an otherwise legitimate user as 'intruder'
makes me at least raise an eyebrow.)

>...
>to fix if you *know* the identity of the real user, 
>and that sometimes it's genuinely hard to know who the real user is,

Do you ever know who the 'real' user is...

>especially across a network where you don't control the other end.

...even on your local machine?

>One way to resolve the latter problem is to always trust the user;

That from *you*? ;-)

>another way is to never trust the user; a middle way is to work hard
>and try to give you some control about how much trust you have.
>
>(Then of course, there are bugs and misfeatures, and the relative
>quantities of these in Unix vs. other OS's is beyond the scope of this note :-)

Simply that Unix doesn't have more bugs than other OSs does in no way
invalidate the statement that it doesn't have as much *features* to
stop legitimate use. Take VMS, for example. Maybe there are less bugs
in it. (Yes, it has bugs, too.) But definitely there are features in
it that serve nobody but paranoid system admins who want to control
every key any user may press, at the expense of memory and CPU time
that otherwise could serve the user. Now tell me what is better ;-)

>But it is a lot easier to do security, and everything else,

Security, as defined above, means unusability - for this I don't need
any OS at all. I switch the machine off.

>if your system has a clean model of reality behind its design.

To define 'reality' is not that easy...

>Tacked-on stuff never does as well, and many of the nice tools on Unix
>really were afterthoughts.

Many of the not-so-nice tools, too.

Olaf
-- 
| Olaf Titz - comp.sc.student  |   o     | uknf@dkauni2.bitnet | old address |
| univ. of karlsruhe - germany |  _>\ _  | s_titz@ira.uka.de   | is still    |
| +49-721-60439                | (_)<(_) | praetorius@irc      | valid       |
  "My heart is human - my blood is boiling - my brain IBM" - Mr. Roboto
Xref: sparky comp.security.misc:2231 comp.org.eff.talk:7652
From: johnsomr@newton.ccs.tuns.ca (Mark R Johnson)
Subject: Re: Fun things to do to RTM (was: Internet worm)
Date: Tue, 15 Dec 1992 15:26:59 GMT
Distribution: inet
Organization: Technical University of Nova Scotia, Halifax, N.S.

In article <1gj3r6INNee5@falcon.natinst.com> cummings@natinst.com (Rodney Cummings) writes:
>In article <1992Dec14.184229.22277@mksol.dseg.ti.com> mccall@mksol.dseg.ti.com (fred j mccall 575-3539) writes:
>>Seems obvious, Peter.  The 'tool' central to the crime is the
>>computer.  Simply don't allow him to work with them for a while.  I'm
>>curious as to just how many people really don't 'get' this; that
>>think, as Mike would have us believe, that we're talking about not
>>letting him go to graduate school or something equally silly.  Of
>>course, if he was working on a C.S. degree, he might have a few
>>problems attending for a while, if not programming on computers was
>>part of his probation.
>
>Enforcement of this hypothetical punishment doesn't seem obvious or simple
>to me, so I guess you can count me as one of those who don't 'get' it.
>
>Are you saying that Morris should be prevented from using computers, or
>just programming them?  For example, if he decided to go back to graduate
>school for a P.H.D. in English, should he be forced to use a typewriter
>to do his thesis?  If word processing is acceptable, then should he be
>allowed to buy a personal computer for that task?
>
>I guess what I'm not clear on is your definition of "don't allow him to
>work with them".  This could range anywhere from not allowing him to do
>computer security work to not using the corner ATM machine.

It's worse than this.  What about all those telco switches that route all
our phone calls.  Are we going to bar people from using the phone?(:-)

On a more serious note,  I have a degree in Electical Engineering.  I am
currently doing a Master's degree that requires intensive computer use.
Were I to be working in EE, I would undoubtedly be using computers on a 
regular basis.  I do not believe that I am in any way unique in this 
respect - ie all my skills require the use of computers on a daily, routine
basis.  I am going to presume that RTM is similar in this respect.  Barring
such a person from computer use is tantamount to sentencing someone to
x years of collecting welfare.  A punishment that makes it impossible to
earn an honest living is not reformation of a criminal, but rather an
inducement to further crime.

Scenario:
Suppose a carpenter was convicted of assault.  Should she be barred from
using hammers for x years because a hammer could be misused (as a 
weapon.)?
>-- 
>     Rodney Cummings            cummings@natinst.com
>     National Instruments       Austin, Texas

--
;---------------------------------------------------------------------
; Mark Johnson             ; msdos has 6 types of RAM - dos ram,
; My views are my own and  ; upper memory, high memory, extended memory,
; nobody else's.           ; expanded memory, and video ram.
;                          ; YUCKKK!!!!!!!!!!!
; flames >/dev/null        ;
;---------------------------------------------------------------------

Newsgroups: comp.security.misc
From: jd@parcival.nwc.navy.mil (John de la Garrigue)
Subject: Re: CERT and the Dept. of Justice on keystroke monitoring
Reply-To: jd@parcival.nwc.navy.mil
Organization: Science Applications International Corporation
Date: Mon, 14 Dec 1992 16:47:25 GMT

In article 3491@nic.csu.net, oleg@gd.cs.csufresno.edu () writes:
>In article <q50qgdg@dixie.com> jgd@dixie.com (John De Armond) writes:
>>strnlght@netcom.com (David Sternlight) writes:
>>
	<stuff about keystroke monitoring notice deleted>
>
>Huh? If I work for company X, X automatically has full rights to read
>my mail or search my home? Or maybe only if it officially warns me
>about this on it's front entrance? :). 
>
>Oleg

No, and that's clearly not what the notice is saying.  If you work for company X,
and use their equipment for whatever reason (notice many companies clearly state
*anything* done using their equipment/software/other resources is their
property, like it or no), the company has a right to make sure what you are doing
is legal and ethical.  If you don't like this type of policy, the simple answer
is to not use someone else's machine.

---
                __
           /  /   \
          /  /    /
   /     /  /    /
  /_____/  /____/

John de la Garrigue                              ||  Phone:  619/546-6192
Senior Unix System Administrator                 ||  Pager:  619/375-0500
Site Manager                                     ||  E-mail: jd@c3ot.saic.com
Science Applications International Corp. (SAIC)  ||  

My views are not necessarily those of my employer, the US government,
or anyone else for that matter.

Newsgroups: comp.security.misc,comp.org.eff.talk
From: charlie@umnstat.stat.umn.edu (Charles Geyer)
Subject: Re: Stupid Licenses (YUCK!)
Organization: School of Statistics, University of Minnesota
Date: Sat, 19 Dec 1992 02:36:09 GMT

In article <bhayden.724690634@teal> bhayden@teal.csn.org (Bruce Hayden) writes
(replying to me):

> Well, the problem is that it is very hard to write software that doesn't
> fail (ever), especially at commercially reasonable prices. So - everyone
> is worried that they will get sued for the failure. This may be because
> software is inhearantly more complex than other forms of engineering
> (at least in my opinion). Ask yourself - how many parts does the averege
> appliance, etc. have? Not that many does it. Now - how about software?
>
> Another problem is that the courts have yet to address the question
> of the normal level of care required in a software program. Is one 
> bug in a 1,000 lines of code inidicative of due care? How about 10
> or 100? How significant is the error? I'm here making it sound
> easier than it really is. More than just software metrics is required.
>
> I am now an expert witness in a software case. My opinion is that the
> software is defective, and that due care was not used in its preparation.
> I think that this case is obvious. Many others are borderline. As a
> plaintiff's attorney, I would argue for a high standard of care. As
> a defense attorney, I would argue for a much lower standard.

I agree that legal liability for buggy software is a knotty problem, but
that's not what's important.  Law suits never improve quality.

It is fair to say that no computer company puts quality first, ahead of
featurality.  Until they do, quality will remain abysmal.

The issue is not whether they exercised "due care" or whether they found
the last bug.  The issue is whether bug fixes for all serious bugs are
provided as a matter of course, and by "serious" here I mean anything that
affects the functionality of the software, and whether product is simply
not shipped with known serious bugs.

Every time I say something like this on the net.  Industry people tell me
that economic realities (according to conventional wisdom) dictate that
deadlines come before quality.  He who ships first gets the customers.

And that's why computers don't work.

(end rant)

-- 
Charles Geyer
School of Statistics
University of Minnesota
charlie@umnstat.stat.umn.edu
Newsgroups: comp.security.misc
From: btb@NCoast.ORG (Brad Banko)
Subject: Re: Killer Cracker
Organization: North Coast Public Access *NIX, Cleveland, OH
Date: Fri, 18 Dec 1992 00:51:50 GMT

In article <1992Dec16.072857.19363@jhunix.hcf.jhu.edu> unclesam@jhunix.hcf.jhu.edu (Sam C Chi) writes:
>	I understand that there's a program called 'Killer Cracker' that can
>crack the encrypted password file on Unix.  Is there an another version/new
>version of Killer Cracker that cracks BSD encryption?  How is the BSD
>encrption different from the original encrption that came out when Unix was
>first developed?  Sorry if I sound clueless, please enlighten me.
>
>					- unclesam@jhunix.hcf.jhu.edu
>
>-- 
>==============================================================================
>Speds 'R Us, "If you can't be first, you can be second."
>We live for cheap porno music "piewch pee piewch tsch tsch"
>                                -The Johns Hopkins Varsity Cross-Country 1992.


No... there is not a version that cracks BSD encrypted passwd files. The most recent ones for DOS are KC9.11, KC9.95, and KC9.10. For dos, KC9.10 is the best,
it uses Math coprocessor emulation routines, and has a 200% to 500% increase in speed.

-- 
______________________________________________

-----Internet : btb@ncoast.org
___________________
From: mj03370@hacgate.SCG.HAC.COM (M.S. Jaffe)
Newsgroups: comp.security.misc
Subject: Re: Security Levels
Date: 15 Dec 92 17:42:53 GMT
Reply-To: mj03370@hacgate.UUCP (M.S. Jaffe)
Distribution: usa
Organization: Hughes Aircraft Co., El Segundo, CA

In article <1992Dec14.232220.8343@cbis.ece.drexel.edu> jpw@lorelei.ece.drexel.edu (Joseph Wetstein) writes:
>Could somebody be kind enough to post (or mail) the definitions (with
>examples, in clear english) of the NSCS security levels/criteria,
>i.e. D, C1, C2, B1, ... etc.
>
>If there are any gov't publications available, how would I get them?
>
>Thanks!
>
>

The levels of security are defined in the Trusted Computer System
Evaluation Criteria (TCSEC, also known as the Orange Book  - it's cover
is orange; it is also a Defense Department standard, DoD 5200.28-STD).
It is part of the rainbow series, so called because the various
reference books, all on the subject of computer security, have
different colored covers - e.g., Orange Book, Red Book, etc.).  They are
available upon request from the National Computer Security Center, 9800
Savage Road, Fort George Meade, Maryland, 20755-6000.  A university
library might well already have a copy, possibly even a full set of the
rainbow series.

Newsgroups: comp.security.misc
From: csgoh@ncb.gov.sg (Goh Cheng Seng)
Subject: Security issues related to Internet
Keywords: security, Internet
Organization: National Computer Board, Singapore
Date: Fri, 18 Dec 1992 09:22:55 GMT

Hi,

I am the administrator of a new Internet site.  Other than our Internet
server (ie. the one that I prepare this article), we have other hosts
running various in-house applications.  Since we are now connected to
The Net, we have some concern over the security threats that may arise.

Just wonder any of you has a list of the potential security problems
that are related to Internet.  Appreciate it if you could send the list
to me through email as I do not read my news daily.

Cheers!

--
========================================================================
GOH Cheng Seng				National Computer Board
Internet: csgoh@ncb.gov.sg		71 Science Park Drive
Bitnet:   CHENGSENG@ITIVAX.BITNET	NCB Building 
Phone:    (065)-7720451			Singapore 0511
========================================================================