HDTenEightyP/NetNews huggingface dataset:
From: dsm@prism.gatech.EDU (Danny McGurl)
Newsgroups: comp.security.misc
Subject: Re: Security Policy
Date: 21 Aug 92 01:12:43 GMT
Organization: Revelstone High Command

In article <BtB4vu.JDB@solbourne.com> imp@solbourne.com (Warner Losh) writes:

>You are right.  I've seen this at many places.  My brother never tires
>of telling me the latest stupid behaviour by the system admins at his
>school.  It is completely revolting.

Well, on the other side of the coin, students at a school tend to have
a one sided view of what's going on.  It's sometimes just a lack of
communication.  Sometimes of course it's justifiable.  If you start looking
for evil in every action of someone, you will find it.

 
>Oh, you forgot to add "hacking sendmail.cf so that root gets a copy of
>all off site mail" to the list of things that they do :-(

This brings up an interesting question.  Where does a sysadmin's
action become unethical and/or illegal.  Is it wrong for a sysadmin
to log the mail and not look at it unless they are presented with
a reasonable suspicion (or evidence of a crime)? 

From a sysadmins point of view, it may be prudent to impliment draconian
policies because of possible ramifications of abuse.  

Have you ever been told to shut all your computers down by the secret
service?  Been supeonead?  It would make me take security very
seriously. 

Disclaimer:  I personally find the idea of spooling the mail is
ugly, but where is the line?
-- 
Danny McGurl                        "No, no Pixel!  Beer is not for baby cats."
Office of Information Technology        --Richard Ames,
dsm@prism.gatech.edu 		        __The Cat Who Walks Through Walls__
Newsgroups: comp.security.misc
From: casper@fwi.uva.nl (Casper H.S. Dik)
Subject: Re: Secure setuid mount program - possible?
Supersedes: <1992Aug19.200655.19273@fwi.uva.nl>
Organization: FWI, University of Amsterdam
Date: Wed, 19 Aug 1992 20:24:07 GMT

unruh@physics.ubc.ca (William Unruh) writes:

>ie,
>execlp("/etc/mount","mount","-t","pcfs","/dev/fd0","/pcfile",(char*)0)

% cp /bin/sh /tmp/mount_pcfs
% set path = ( /tmp $path)
% <your-mount-program>
# 

When the environment is concerned there are two basic rules:

	- if you spawn a process as the original user - keep it.
	  (E.g., xterm, screen)
	- if you spwan a process as another user - kill it TOTALLY
	  (E.g., sendmail)

Programs as su & login are a bit different. I the normal case
they give access as another user. In that case no special care is
needed. Su & login must take care that a number of special
env vars are filtered. Which vars depends largely on the OS.

To give an example of really weird misuse of env vars (when using a C-shell
script as ``login shell'' of a user without a password).

/bin/somescript is a script that performs a root function for users
of a system. It is a C-shell script.

someuser::0:0:Pseudo user to perform Somefunction:/:/bin/somescript

Normal usage:

% su someuser
Thank you for performing some function!!

Now watch this:

% setenv TERM '`/bin/chmod 666 /etc/passwd; echo done > /dev/tty`'
% su someuser
done
<hangs-type your intr char>

The point is this: you should totally clean out the environment.
You have no way of knowing what variables are used and/or will
be used in the future. Not just junk IFS, cleanup PATH, 
remove the lot.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl

-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
Newsgroups: comp.security.misc
From: dave@carina.unm.edu (Dave Grisham)
Subject: Re: Security Policy
Date: Wed, 19 Aug 92 22:53:36 GMT
Organization: University of New Mexico, Albuquerque

Some security policies and many ethics policies may be found
by ftping to ariel.unm.edu  directory is ethics.
grish
Newsgroups: comp.security.misc
From: craig@ec.uwa.oz.au (Craig Richmond - division)
Subject: Re: Fake headers on Internet mail
Organization: University of Western Australia
Date: Fri, 14 Aug 1992 09:22:59 GMT

Barrett_Jim@ial3.jsc.nasa.gov (Jim Barrett) writes:

>I have observed that some mailer daemons are able to detect certain fraudulent
>transcations, and while accepting the "From:" information in the incoming
>message, will also include an "Apparently-From:" line in the message header. 
>Most mailers that I have played with believe the "From:" information fed to
>them without a murmur of doubt.  

The Apparently To: field is generated if you fail to put a Mail header in
the mail body and it has to be salvaged from the envelope information.
Similarly the Apparently From: field is probably placed in the mail if the
envelope information must be used to generate it and can probably be
circumvented by including the information in the Body of the message as
well as the SMTP envelope information.

Craig
--
Craig Richmond.  Computer Officer -  Dept of Economics (morning) 380 3860
  University of Western Australia    Dept of Education (afternoon)
craig@ecel.uwa.edu.au                              Dvorak Keyboards RULE!
     "Only users are allowed to make messes on their computers"  I.M.VI
Newsgroups: comp.security.misc
From: a74k110@titan.ucc.umass.edu (Chris Lloyd)
Subject: Re: trapdoor passwords
Organization: University of Massachusetts, Amherst
Date: Thu, 13 Aug 1992 02:00:48 GMT

In article <1259@eplunix.UUCP> raoul@eplunix.UUCP (Nico Garcia) writes:
>In article <BssuF5.G4@ibmpcug.co.uk>, gtoal@ibmpcug.co.uk (Graham Toal) writes:
>> Has anyone heard a rumour circulating that some crackers have found a
>> trapdoor password that lets people on to Next machines with root
>> privs?  I told the person I heard it from that it sounded like total
>
>I heard this one too: I was told that there was a "backdoor". This struck me
>as reasonable, since the NeXT was developed for fun and the NetInfo programs
                               ^^^^^^^^^^^^^^^^^^^^^
That's a good one, I'm sure the Wall Street Firms using it to develop
trading programs would certainly call it "fun"...

[...blah blah]
>Upon checking, my rumor source forwarded a copy of a note from a private bbs
>that complained of security *holes* on NeXT, but made no mention of actual
>backdoors. I then explained to my rumor source the distinction between the
>two, and have heard nothing further.

As with any computer, the NeXT has it's share of security holes, you're kidding
yourself if you think you most computers are secure out of the box.

As for whether the NeXT has a "backdoor" password, I *REALLY* *REALLY*
*REALLY* doubt it. I would wager this rumor is one of those permuted
rumors, starting out as someone hearing about the loginwindow special
account names (which are undocumented)

The loginwindow program used to login on the console has two special account
names "exit" and "console", exit will stop and restart the windowserver
(handy for some uses) and console will quit the windowserver and bring
up the system console upon which you login in via a getty process
running on /dev/console.  This "backdoor" password rumor is very
likely to have mutated from this feature of the loginwindow program.

la la la,
-- 
:: Christopher Lloyd :: a74k110@titan.ucc.umass.edu :: Yrrid, Inc. ::
From: unruh@physics.ubc.ca (William Unruh)
Newsgroups: comp.security.misc
Subject: Re: Secure setuid mount program - possible?
Date: 19 Aug 92 16:57:10 GMT
Distribution: comp
Organization: University of British Columbia, Vancouver, B.C., Canada

k2@bl.physik.tu-muenchen.de (Klaus Steinberger) writes:

>buzz@toxicavenger.bear.com (Buzz Moschetti) writes:

>>We wish to make mount and umount available to two or three non-root accounts.
>Its really no problem for an advanced user, to put a sh onto a
>floppy, and make it setuid root. You could forbid access to the raw
>floppy, so that nobody could fiddle around with an unmounted filesystem,
>but that's no real security, as you could fiddle with the bits on any dump PC.
I have a similar question but with mount -t pcfs on the Sun- Since it is
mounting a Dos filesystem, and since there is no ownership info on a dos
disk ( and no suid) Is it safe from floppy games (other than rebooting
from the floppy of course)
ie,
execlp("/etc/mount","mount","-t","pcfs","/dev/fd0","/pcfile",(char*)0)
Bill Unruh
unruh@physics.ubc.ca
From: rouilj@cs.umb.edu (John P. Rouillard)
Newsgroups: comp.security.misc
Subject: Re: RFC931 (was Re: Fake headers on Internet mail)
Date: 18 Aug 92 16:15:32 GMT
	<ROUILJ.92Aug16141523@dl5000.bc.edu>
	<1992Aug17.041338.4472@news.iastate.edu>
Organization: University of Massachusetts at Boston


In article <1992Aug17.041338.4472@news.iastate.edu> john@iastate.edu (John Hascall) writes:

   rouilj@dl5000.bc.edu (John P. Rouillard) writes:
   }>   Why don't I trust root? I don't know you. And, on the majority of UNIX
   }>   machines it is fairly simple for any user to become root.

   }Well, how simple it is depends on the system. Currently I have systems
   }that can be rebooted into root mode.  However, when that is done, the
   }experimental rfc931 server (no, it is not available for public access
   }or use yet) that runs on that machine loses its encryption key. Thus
   }by getting an rfc931 identifier that says "rouilj" I can tell you
   }immediately that it isn't a valid identifier since there was no way
   }you should be able to get an unencrypted identifier out of one of my
   }properly operating servers.  Thus there is a high degree of
   }probability that that letter was forged.

   If I were the user who booted into root mode I would also fire up
   a simple daemon on the rfc931 port which always answered every
   request with "SDdf;sadf344sagfarg" (or whatever identifier I had
   seen myself recently in mail to me).

Sigh, that's the problem with simple examples. In reality, you would
throw a timestamp in with the user ID that would provide a check
on the timestamps on the message itself.  In additition a random
salt of a length sufficient to make known text attacks
on the encrypted string difficult should be put on the front of the
unencrypted string and the string encrypted with des in CBC mode.

Hopefully that's a better explanation.

-- John
From: ables@hal.com (King Ables)
Newsgroups: comp.security.misc
Subject: Re: SMTP SECURITY: A new (?) idea
Date: 13 Aug 92 15:15:14 GMT
Organization: HaL Computer Systems, Inc.

From article <1992Aug13.102249.16853@jarvis.csri.toronto.edu>, by flaps@dgp.toronto.edu (Alan J Rosenthal):
>
> These
> forgers will include system administrators and also people who break in to
> privileged accounts.

As a former sysadm, I take offense at this remark and I think many current
ones will, too.  I will give you the benefit of the doubt and assume you are
not trying to say that sysadms are, by nature, underhanded individuals (which
is what it sounds like) but that you simply chose a poor way of trying to
say that only privileged users would be able to accomplish such a feat, but
that many people could get these privileges in different ways.

It *is* true that someone with the root password can do pretty much anything
they want.  One of the most important qualities in a good sysadm is honesty
integrity because they *do* have the power to do so much and it would be very
easy to abuse it.  They also need the intelligence to know what is reasonable
and what is not.  Most do.

But the basic point is sound.  Whoever can be root can obtain "authorization"
to look official, so from another machine, why is that enough to make you
believe?  I can become root on my machine right now simply by rebooting it.
I am not the system administrator here, I'm just one of many users.  Just
because I say I'm root, doesn't mean your machine should trust me to do
whatever I want!
---------------------------------------------------------------
King Ables                    HAL Computer Systems, Inc.
ables@hal.com                 8920 Business Park Dr., Suite 300
+1 512 794 2855               Austin, TX  78759
---------------------------------------------------------------
From: mark@hpcvxmsr.cv.hp.com (Mark Rowe)
Newsgroups: comp.security.misc
Subject: Re: Covert channel
Date: 17 Aug 92 21:19:06 GMT
Reply-To: mark@hpcvlx.cv.hp.com
Organization: UDT-CV (ITO)

In article <FAIGIN.92Aug17115056@soldan.aero.org> Daniel P. Faigin writes:
>On Mon, 17 Aug 1992 17:51:23 GMT, mark@hpcvxmsr.cv.hp.com (Mark Rowe) said:
>> It is true that properly implemented MAC would prevent the use of my
>> example.  That does not in any way prevent this from being an example
>> of a covert channel, it's simply a covert channel that can be eliminated
>> by MAC.  
> 
> Wrong, bucko! If properly implemented access controls would close the channel,
> then the channel is a *flaw*, not a covert channel.

It's only a flaw if there is something to be flawed.  On a C2 system there is
no MAC, I would argue my example still denotes a covert channel and not a
flaw in the non-existant MAC.

>> MAC does not define a covert channel.  

> I'd agree with you on this; however, covert channels other than MAC-type ones
> aren't interesting. Why would I care about a DAC covert channel, when I just
> just exploit the weaknesses inherent in DAC.

If what you are saying is that my example is an uninteresting covert channel
then I may agree with you.

>> What defines a covert
>> channel is how the data is being transmitted.  It is either overt or
>> covert.  An overt channel is a channel that transmits data in a known
>> manner as intended by the system administrators.  A covert channel is
>> anything else.

> Judging intent, however, is quite difficult. Let's take some examples here.
> Suppose I have a system where I can observe contention for a system resource,
> say memory. I exploit this to transmit information. That's a clear channel.
> Other cases aren't so clear. Look at Unix. There are many ways I can
> communicate with processes. Are signals a covert channel? Is the use of ptrace
> a covert channel? Is the use of the process number address space a covert
> channel? 

> It's not always so clear cut (alas).

I agree, it is not always clear cut, but I think the wrong questions are being
asked.  It is not, "Is the use of XXX a covert channel?", but rather, "Was XXX
intended to transmit information about YYY?".  It is (as you said) this intent
that is often not clear cut.  That in itself is not a fault in the definition.
It is often much easier to define what something is than it is to accurately
identify one when it is encountered.

Mark Rowe             email: mark@hpcvlx.cv.hp.com
Hewlett Packard       voice: (503) 750-3246
Corvallis, OR         FAX:   (503) 750-3788
From: spencer@phoenix.Princeton.EDU (S. Spencer Sun)
Newsgroups: comp.security.misc
Subject: Re: SMTP SECURITY: A new (?) idea
Date: 13 Aug 92 16:18:23 GMT
Reply-To: spencer@phoenix.princeton.edu (S. Spencer Sun)
Organization: Live Organ Transplants

In article <1992Aug13.151514.14735@hal.com>, ables@hal.com (King Ables) writes:
>From article <1992Aug13.102249.16853@jarvis.csri.toronto.edu>, by flaps@dgp.toronto.edu (Alan J Rosenthal):
>>
>> These
>> forgers will include system administrators and also people who break in to
>> privileged accounts.
>
>As a former sysadm, I take offense at this remark and I think many current
>ones will, too.  I will give you the benefit of the doubt and assume you are
>not trying to say that sysadms are, by nature, underhanded individuals (which
>is what it sounds like) but that you simply chose a poor way of trying to
>say that only privileged users would be able to accomplish such a feat, but
>that many people could get these privileges in different ways.

I don't see why you're so offended.  He's not saying that you're
immoral, or that all sysadmins are immoral.  I think you're correct that
he didn't mean that sysadmins are, by nature, underhanded inviduals.  I
think he meant that some individuals who are underhanded somehow end up
as sysadmins and would use the position for their personal gain.  I have
to agree that the possibility exists.

>It *is* true that someone with the root password can do pretty much anything
>they want.  One of the most important qualities in a good sysadm is honesty
>integrity because they *do* have the power to do so much and it would be very
>easy to abuse it.  They also need the intelligence to know what is reasonable
>and what is not.  Most do.

Yeah, well, implication is that some don't, right?  Idealism is nice,
but reality is better.

IMHO the point the original poster had in mind is that even if you went
through with the privileged port idea (ignoring for the moment the 3
points against it raised in another article), that it wouldn't eliminate
the problem of mail forging, it would just restrict potential culprits to
a smaller pool of individuals.

----------- The opinions expressed in this article are solely mine. -----------
<Insert lame attempt at disclaimer humor>
sss/PU'94 Dept of CS (spencer@phoenix.princeton.edu)/JvNCnet (spencer@jvnc.net)
"Was it a dream where you're standing in sort of sun-god robes, on a
pyramid, and a thousand naked women are screaming and throwing little
pickles at you?"  "No."  "Why am I the only one that has that dream?"
From: mark@hpcvxmsr.cv.hp.com (Mark Rowe)
Newsgroups: comp.security.misc
Subject: Re: trapdoor passwords
Date: 12 Aug 92 21:20:59 GMT
Reply-To: mark@hpcvlx.cv.hp.com
Organization: UDT-CV (ITO)

In article <BssuF5.G4@ibmpcug.co.uk>, gtoal@ibmpcug.co.uk (Graham Toal) writes:
> ... found a trapdoor password that ...
              ^^^^^^^^
Do you mean backdoor password?
Newsgroups: comp.security.misc
From: faigin@aero.org (Daniel P. Faigin)
Subject: Re: Covert channel
Organization: The Aerospace Corporation, El Segundo, CA
	<FAIGIN.92Aug17115056@soldan.aero.org>
	<1992Aug17.211906.7142@hpcvusn.cv.hp.com>
Date: Tue, 18 Aug 1992 19:03:28 GMT

On 17 Aug 92 21:19:06 GMT, mark@hpcvxmsr.cv.hp.com (Mark Rowe) said:
> It's only a flaw if there is something to be flawed.  On a C2 system there is
> no MAC, I would argue my example still denotes a covert channel and not a
> flaw in the non-existant MAC.

If you are talking about C2 systems, then what you have is an overt flow of
information. A channel cannot be covert if there is no policy to bypass.

Daniel
--
[W]:The Aerospace Corp. M1/055 * POB 92957 * LA, CA 90009-2957 * 310/336-8228
[Email]:faigin@aerospace.aero.org              [Vmail]:310/336-5454 Box#13149
   "You can't be a rationalist in an irrational world. It isn't rational!"
	       Dr. Rance, in Joe Orton's "What the Butler Saw"
Newsgroups: comp.security.misc
From: c8908461@jupiter.newcastle.edu.au (Robert Lang)
Subject: FAQ ? Encrypt() Source ?
Organization: Uni of Newcastle, Australia
Date: Sun, 16 Aug 1992 04:15:27 GMT

I'm writing a simple password protection system in C (very simple), but
would like it if the password was nicely encrypted....

Anyone have some source for non-reversible encryption ???

Thanks,

Robert.

P.S. I don't usually read this newsgroup, please reply through email.

Newsgroups: comp.security.misc
From: franco@fx.com (Frank Minjarez)
Subject: Re: Covert channel
Organization: FXD/Telerate, Mountain View, CA
Date: Thu, 13 Aug 1992 21:48:23 GMT

flaps@dgp.toronto.edu (Alan J Rosenthal) writes:

>ho@cs.arizona.edu (Hilarie Orman) writes:
>>I've always relied on the notion of information flow - if the writer
>>of the transmitter program did not specify the information as an
>>output, and if a receiver program can detect the information, then you
>>have a covert channel,

>But the usual covert channel demonstration involves having a transmitter
>program which was written just for the purpose of transmitting the data.
>This is surely output, even if it's not output to a file.

The definition in "Computer Security Basics" [published by O'Reilly & 
Associates] is a good one:

	"A communication channel that allows a process to transfer information
	in a way that violates a system's security policy."

I think the key points here are "communication channel" and "violates
security policy."  Some process has to communicate (eg write to disk, send
over phone line, etc.) data to another process, and that communication 
has to violate the security poilicy of the system (eg not to write out
classified data to processes that are not trusted to read it).

It may be a process that intentionally writes data for another process to 
read, or one that does it inadvertantly.  Similarly, the reader can read the
data intentionally or not, it doesn't matter.

hope that helps,
--f
From: nelson@reed.edu (Nelson Minar)
Newsgroups: comp.security.misc
Subject: RFC931 (was Re: Fake headers on Internet mail)
Date: 14 Aug 92 19:17:48 GMT
Article-I.D.: reed.1992Aug14.191748.11505
Organization: Reed College, Portland, OR

In article <1992Aug14.173113.5978@fwi.uva.nl> casper@fwi.uva.nl (Casper H.S. Dik) writes:
>I don't understand what all this complaining against RFC 931 is about.

First of all it seems like not many sites are running RFC 931 type
code. I don't know why this is, but it makes it considerably harder to
count on it for authentication. 

I do think RFC 931 would improve security on the Internet, but not by
very much..

Quoting from RFC 931:

"Unfortunately, the trustworthiness of the various host systems that
might implement an authentication server will vary quite a bit.  It is
up to the various applications that will use the server to determine
the amount of trust they will place in the returned information."

No kidding. I don't trust root@some.site at all. I don't let root NFS
mount my disks, I don't let root rsh to my machine. In particular, I
don't trust anything a restricted port tells me.

Why don't I trust root? I don't know you. And, on the majority of UNIX
machines it is fairly simple for any user to become root.

It is likely that RFC 931 style authentication would be useful in
stopping most forged mail - not many people are going to bother
hacking root just to forge a letter. But as a general protection
scheme it is not very useful.
-- 
                __
nelson@reed.edu \/    The look in his eyes when it hit - kid, it was tasty...
From: rouilj@dl5000.bc.edu (John P. Rouillard)
Newsgroups: comp.security.misc
Subject: Re: RFC931 (was Re: Fake headers on Internet mail)
Date: 16 Aug 92 19:15:23 GMT
	<1992Aug14.173113.5978@fwi.uva.nl> <1992Aug14.191748.11505@reed.edu>
Organization: Institute for Space Research, Boston College


In article <1992Aug14.191748.11505@reed.edu> nelson@reed.edu (Nelson
Minar) writes:

>   I do think RFC 931 would improve security on the Internet, but not by
>   very much..
>
>   [ quote from rfc931 about trustworthyness deleted]
>
>   No kidding. I don't trust root@some.site at all. I don't let root NFS
>   mount my disks, I don't let root rsh to my machine. In particular, I
>   don't trust anything a restricted port tells me.

Yes, but the rfc931 information is there for root@some.site to use,
and not for you to use. If I wanted to I could provide an encrypted
name as my rfc931 identifier.  You wouldn't know that
"SDdf;sadf344sagfarg" was "rouilj".  However, if you told me that you
had what you believed to be a forged letter with this rfc931 id, I
could use that info to find out that it was sent from the rouilj
account.

>   Why don't I trust root? I don't know you. And, on the majority of UNIX
>   machines it is fairly simple for any user to become root.

Well, how simple it is depends on the system. Currently I have systems
that can be rebooted into root mode.  However, when that is done, the
experimental rfc931 server (no, it is not available for public access
or use yet) that runs on that machine loses its encryption key. Thus
by getting an rfc931 identifier that says "rouilj" I can tell you
immediately that it isn't a valid identifier since there was no way
you should be able to get an unencrypted identifier out of one of my
properly operating servers.  Thus there is a high degree of
probability that that letter was forged.

I won't get any valid audit info from that connection, but I do know
for certain that something was rotten in the state of Denmark.

What would be ideal for this scheme is a public key system. That way,
you could validate the rfc931 identifier, but until the patents wear
off, that is unlikely.

-- John
Newsgroups: comp.security.misc
From: gary@nexnix.demon.co.uk (Gary Howland)