HDTenEightyP/NetNews huggingface dataset:
From: walsh@cs.umass.edu (Norman Walsh)
Newsgroups: comp.fonts
Subject: Re: Coca-Cola font request
Date: 1 Sep 92 12:32:18 GMT
	<BtoGp1.Dtn@andy.bgsu.edu>
Reply-To: walsh@cs.umass.edu
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
In-reply-to: ckile@andy.bgsu.edu's message of 28 Aug 92 05:02:59 GMT

It's already on ftp.cica.indiana.edu in /pub/pc/win3/fonts

                                                    norm
From: jaap@alice.att.com (jaap)
Newsgroups: comp.fonts
Subject: Re: Unicode and Fonts
Date: 26 Aug 92 18:02:15 GMT
Article-I.D.: alice.23558
Reply-To: jaap@alice.UUCP ()
Organization: AT&T, Bell Labs

In article <mcdonald.244@aries.scs.uiuc.edu> mcdonald@aries.scs.uiuc.edu (J. D. McDonald) whines:
 > 
 > I don't care one whit about your arguments, I want ligatures.
 > 

Next time, try writing Santa Claus.

	jaap
From: bkph@wheat-chex.ai.mit.edu (Berthold K.P. Horn)
Newsgroups: comp.fonts
Subject: cpp
Date: 27 Aug 92 00:49:07 GMT


re: How to compute characters per pica (cpp).
---------------------------------------------

Anyone know the official letter mix for computing cpp?

The `Adobe Type Guide' lists the average linear character density for
each text font.  What is the assumed character mix?  Are only lower
case characters considered?  Is the space `character' (the most
frequent in the English language) considered?

One can come fairly close to their numbers assuming a letter mix
found in the typical cryptographic book and ignoring upper case and
space.  But it would be nice to know the actual mix used so fonts not
in the Guide can be compared with those in the Guide.

Berthold K.P. Horn
Cambridge, Massachusetts, USA
From: Quinn <quinn@cs.uwa.edu.au>
Subject: Re: Unicode and Fonts
Organization: The University of Western Australia
X-Useragent: Nuntius v1.1
     <27238@life.ai.mit.edu> <5154@dove.nist.gov>
Date: Thu, 27 Aug 1992 02:28:25 GMT

In article <mcdonald.244@aries.scs.uiuc.edu> J. D. McDonald,
mcdonald@aries.scs.uiuc.edu writes:
>I don't care one tiny hoot for the Asian hieroglyphics.

Yeah but there are an awful lot of Asians out there who do.

{$push} {$setc OutrageousFlameBait=true}

Face facts, the Japanese have destroyed every major American
industry that they've set their sights on eg motor cars, consumer
electronics, commodity semiconductors.  It's well within the
bounds of possibility that one day they'll do the same to the
personal computer industry.  For example of how this might be done
look at the inroads they're making into the supercomputer market.

It might be wise to force through character set unification while
you still have the clout to impose things like the Han unification
on the Japanese rather than have the Japanese impose (equally
controversial) standards on you.

{$pop}

Have a nice day (-:

Quinn "The Eskimo!"      <quinn@cs.uwa.edu.au>     "Support HAVOC!"
Department of Computer Science, The University of Western Australia
  -- Yes I realise this is "Outrageous Flame Bait".  Just think
     of it as one non-American opinion of the way the world is heading.
From: James_Zuchelli@qm.claris.com (James Zuchelli)
Newsgroups: comp.fonts
Subject: RE: Remington and Checks
Date: 4 Sep 92 01:27:37 GMT
Distribution: na
Organization: Claris Corp

The Font Shop, which I believe is in Toronto, Canada, has a font that looks
like an old-fashioned typerwriter.  they have several variations, one which
looks like from a new ribbon, with ink clogs, and one from an old ragged ribbon
and a nice readable one.

However, the fonts are designed for high resolution imaging (linotronic type.)

Adobe makes a font called MICR which uses the numbers found at the bottom of
checks.

Both fonts are PostScript.
From: sdyck@ccu.umanitoba.ca (Sheldon Dyck)
Subject: Script font found in mathematics journals
Organization: University of Manitoba, Winnipeg, Canada
Date: Tue, 1 Sep 1992 18:28:37 GMT

Does anyone know where I can locate the fancy script font that is used in many
mathematics journals such as Bulletins of the American Mathematical Society?
I have looked on ymir.claremont.edu but no luck. Any help would be very much
appreciated. Thank you.

+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Sheldon Dyck    <sdyck>                     | 58 Pincarrow Road         |
| Department of Mathematics,                  | Winnipeg, Manitoba.       |
| University of Manitoba.                     | Canada,  R3Y-1E3.         |
| e-mail: sdyck@ccu.UManitoba.CA              | (204)-488-6990            |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=+
From: adam@calliope.uucp (Adam Shostack)
Newsgroups: comp.security.misc
Subject: Re: hushlogin
Date: 27 Aug 92 21:48:59 GMT
Organization: Aiken Computation Lab, Harvard University

In article <1992Aug27.200330.24859@news.duc.auburn.edu> hendefd@woof.duc.auburn.edu writes:
>What is a .hushlogin file and why does my system have an empty 
>one in /usr/spool/uucppublic?

From Sun login(1)

     When successful, login updates accounting files, prints disk
     usage  and  limits (by running quota(1),) prints the message
     of the day, informs you of the existence of  any  mail,  and
     displays  the  time  you last logged in.  None of these mes-
     sages is printed if there is a .hushlogin file in your  home
     directory.   This  is  mostly  used  to make life easier for
     nonhuman users, such as uucp(1C).

The crackers may have used this file to store data, stolen passwords,
etc.

Since the contents of .hushlogin (so far as I know) are ignored, this
is a fairly good place to hide something.

Adam



Adam Shostack 					adam@das.harvard.edu

What a terrible thing to have lost one's .sig.  Or not to have a .sig
at all.  How true that is.
From: roxi@mips2.ma30.bull.com (Roland Buresund)
Newsgroups: comp.security.misc
Subject: Privilegies and Threads
Summary: Privilegies and Threads
Keywords: Security, Privilegie, Threads
Date: 2 Sep 92 14:59:17 GMT
Reply-To: r.buresund@frec.bull.fr
Followup-To: comp.security.misc
Organization: Bull HN Information Systems Inc.

Hi all.

I'm wondering if anybody has any experience regarding
threads/light-weight-processes and privilegies in a secure system ?

The reason I'm asking is that I'm a bit confused how to handle
privilegie bracketing in a multi-threaded program.

Will all threads share the same effective privilegie and I as an
application programmer has to protect the possible conflicts that may
arise or will each thread has it's own effective privilegie ?

I've been trying to find anything in Posix 1003.6/D12 about threads,
but they don't seem to acknowledge the existance of P1003.4 and
P1003.4a at all.

So in short:
        - Does any multi-threaded secure O/S that uses privilegies
          exists, and if Yes, how has it been solved ?
        - System V Release 4 ES/MP is supposed to have threads and
          security, does they have privilegies on a per-thread or per-
          process basis ?

Any answer is appreciated.

--
Roland Buresund
r.buresund@frec.bull.fr
Newsgroups: comp.security.misc
From: karger@osf.org (Paul A. Karger)
Subject: Re: Covert channel
Organization: Open Software Foundation
Date: Wed, 26 Aug 1992 18:30:40 GMT

In article <20477@optima.cs.arizona.edu>, ho@cs.arizona.edu (Hilarie Orman) writes:
|> In article <1992Aug12.204649.4110@osf.org>, karger@osf.org (Paul A.
|> Karger) writes: 
|> > Covert channels involve illicit communications between two processes,
|> > a transmitter process that is running a Trojan horse, and a receiver
|> > process that belongs to a spy.
|> 
|> You seem to imply that it can't be a covert channel without intent.
|> 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, a concept further divided into storage and
|> timing channels.
|> 
|> If you don't agree, what alternate term would you use to describe the
|> password inference problem originally described?

Covert channels are only of interest when there is intent.  The password 
inference problem from the page faults on TOPS-20 was an argument validation
problem.  Argument validation says (among many other things) that you
should COPY your arguments from user space into kernel space to avoid
asynchronous attacks.  TOPS-20 wasn't bothering to do the copy.

Not everything is a covert channel.   Many classes of operating system
penetrations reveal information that the O/S did not intend to reveal, but
those are not covert channels.  They are operating system security flaws.
Covert channels specifically involve a Trojan horse in untrusted code 
running at a high security level causing information to flow to a spy at
a low security level.  An operating system flaw that allows me to run
kernel-mode code of my choice certainly can lead to improper information
flow, but it isn't a covert channel.

	- Paul
From: hendrick@ctron.com (Jim Hendrick)
Newsgroups: comp.security.misc
Subject: Q: Setting up NIS in a secure manner.
Date: 3 Sep 92 14:38:01 GMT
Distribution: comp
Organization: Cabletron Systems Inc.

Hi All,
	I have a question. Have any of you set up NIS in such a way
that:
	- The NIS servers only allow a certain set of clients to bind
	to them. THis could be a set of network addresses in certain
	ranges or an explicit list of ethernet addresses, hostnames,
	or IP addresses.

	- The Clients only allow themselves to bind to this certain set
	of NIS servers.

	- The NIS password maps are not generally obtainiable. By
	this I mean that the client machines use the maps for login
	authentication, BUT J.Fred.User cannot obtain the encrypted
	passswords.

	This would need to be implemented on a very diverse set of
machines. We currently run: Sun SPARCs (under 4.1.x and Solaris),
DECstations (2100, 3100, 5000 all running 4.2 variations), SGI
(Indigos and Irises running IRIX 4.0.x), IBM (rs6000 320s, 340s
running AIX 3.2.x). Note that most of these platforms do NOT use
a shadow password file. Is this a *very difficult thing to do*
or not? What hardware/software do you use for the NIS servers?

	If any of you care to reply/comment/question me further,
please do so at my email address and I will summarize if it seems
warranted.

Thanks!!

Jim
--
###########################################################################
### Jim Hendrick (hendrick@ctron.com)   ###                             ###
### Cabletron Systems Inc.		###   " My opinions, etc are    ###
### P. O. Box 5005			### exclusively the property	###
### Rochester, NH 03867-5005		### of nobody in particular."	###
### (603) 332-9400 x1457		###				###
### fax:(603)332-1019			###                             ###
###########################################################################
Newsgroups: comp.security.misc
From: karger@osf.org (Paul A. Karger)
Subject: Re: covert channels
Organization: Open Software Foundation
Date: Wed, 2 Sep 1992 22:37:21 GMT

In article <1992Aug20.214220.22820@cbnewsl.cb.att.com>, fec@cbnewsl.cb.att.com (f.e.carey) writes:

|> 
|> If file permission settings prevent me from reading the daily 
|> files that contains records of production defects in the factory,
|> the access controls forbiding such access could be
|> said to be functioning.  Yet if I am able to determine
|> the size of the files I can infer information about
|> defect rates.  In such a case there would seem to be
|> no "sending process". 
|> Does such a scenario qualify as a covert channel?

There are two potential security problems here.  First, the size of 
the file could imply the defect rate.  This is an example (albeit
a strange example) of the statistical database inference problems
that Dorothy Denning has written extensively about.

There is a second problem that is a covert channel, namely that
a Trojan horse program could modulate the size of the file (or
files) to encode information.  This is a covert channel.

|> 
|> Another scenario: If I've being held incommunicado in a
|> building and denied access to phones, mail, etc. and I am 
|> able to signal out a message using the venetian blinds, 
|> Have I utilized a covert channel?

Yes - in fact, the classic example of a covert channel is a POW
banging on the walls to communicate with other POWs.
From: shmeck@west.darkside.com (The Shmeckhouser)
Newsgroups: comp.security.misc
Subject: Re: CRYPTOGRAPHY INFO WANTED...PLEASE!
Keywords: CRYPTOGRAPHY DES RSA
Date: 22 Aug 92 22:51:01 GMT
Organization: The Dark Side of the Moon +1 408 245 SPAM

u9048979@cc.uow.edu.au (glen eastment) writes:

> If anyone has some files on cryptography, mainly DES, RSA (but any others
> too), could they please e-mail them to me.
> 
> Thanks in adcvance!
> 
> <GE> a.k.a. u9048979@wampyr.cc.uow.edu.au

Should I encrypt them?
Newsgroups: comp.security.misc
From: casper@fwi.uva.nl (Casper H.S. Dik)
Subject: Re: hushlogin
Organization: FWI, University of Amsterdam
Date: Fri, 28 Aug 1992 07:43:44 GMT

hendefd@woof.duc.auburn.edu (Frank Henderson) writes:

>I checked the FAQ and searched all available posts and RT_M, but
>I can't find any info on hushlogin as mentioned in CERT-92:14 -->

>       2. If the check from (A.1) indicates that your binaries have been
>	   modified, check for the presence of a password
>	   log file.  Since the name of the logfile is often changed,
>	   the name of the file should be obtained using the
>	   "strings(1)" command on the Trojan login, uucpd, or telnet
>	   binary.  Examples of filenames used on other systems are:

>                               "/usr/spool/. " (dot space)
>                               "/var/spool/secretmail/.l"
>                               "/var/spool/secretmail/.log"
>                               "/var/spool/secretmail/.tty"
>                               "/var/spool/secretmail/.lock"
>                               "/usr/tmp/.log"
>                               "/usr/spool/uucp/.sys"
>                               "/usr/spool/uucppublic/.hushlogin"

>What is a .hushlogin file and why does my system have an empty 
>one in /usr/spool/uucppublic?

A .hushlogin prevents startup messages (like /etc/motd and
``You have mail''). .hushlogin is also recommended for
non human users, as the contents of /etc/motd can confuse
e.g., uucico. That is precisly the reason (I think) that
Sun ships an empty .hushlogin file in /usr/spool/uucppublic.

If things are normal, /usr/spool/uucppublic/.hushlogin has the same
last modified date as the bulk of the OS files.

Casper
-- 
						|	Casper H.S. Dik
						|	casper@fwi.uva.nl
From: jfh@rpp386.lonestar.org (John F. Haugh II)
Newsgroups: comp.security.misc
Subject: Re: Covert channel
Date: 28 Aug 92 12:57:01 GMT
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: River Parishes Programming, Austin, Republic of Texas

In article <1992Aug27.080947.10737@sniap.mchp.sni.de> frank@D012S436.sniap.mchp.sni.de writes:
>So no security policy can ever be violated, because anything you may be
>able to do must have been "permitted".  Cracked somebody's password?  
>Well you were able to do it weren't you?  Doesn't violate the security 
>policy then, does it?  
>
>There is a difference between "security policy" (a written document),
>its translation into system level parameters, and the *enforcement* of 
>those parameters.

Perhaps there is a difference in the word "permit" between English and
German, but in English the word "to permit" means that one has not only
the ability, but also the authorization (what might be thought of as
``permission'').

Someone seldom has ``permission'' to crack passwords, though the ability
often exists.  An analogy is, you are ABLE to smash in my window and
enter my house, but you are not PERMITTED to do so.  It's the grade
school "can" and "may" argument.
-- 
John F. Haugh II                   | "The US Government has the Midas Muffler
Ma Bell: (512) 251-2151            |  touch: everything they touch turns to
UUCP: ...!cs.utexas.edu!rpp386!jfh |  shit."
Domain: jfh@rpp386.cactus.org      |                  -- Jay Maynard
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Newsgroups: comp.security.misc
Subject: Re: Summary: Re: Disabling telnetd and ftpd etc
Date: 3 Sep 92 05:06:27 GMT
Organization: Rensselaer Polytechnic Institute, Troy, NY

Rob J. Nauta writes:
>daniel@vcp1.vcp.monash.edu.au writes:
>>* Don't run YP or NFS

>Furthermore, it's ok to run NIS and NFS (although with one machine it's not
>needed), if you set up your router to block access to ports 111

Blocking access to port 111 may not completely protect YP.

You need the Iris equivalent of sun-patch 100482 (ftp.uu.net:
/systems/sun/sun-dist)  (/var/yp/securenets, and all that.)

Brian
Newsgroups: comp.security.misc
From: timw@sequent.com (Tim Wright)
Subject: Re: Disabling telnetd and ftpd for security
Organization: Sequent Computer Systems, Inc.
Date: Fri, 28 Aug 92 11:24:36 GMT

In <1992Aug27.174729.1@vcp1.vcp.monash.edu.au> daniel@vcp1.vcp.monash.edu.au writes:


>We are in the process of being connected to the network.  Most connected
>computers will be PC's used for mail and telnet and ftp. 
>We have one Iris 4D which it would be really useful to have connected.
>Our head of department is very concerned about security with regards
>to academic/industrial espionage.

What do you mean by the network ? Your local network or the internet ?
If you're connecting to the internet, your access will be through a
router e.g. a CISCO. These have very sophisticated abilities to filter
packets such that e.g.
incoming requests to port25 (SMTP) are allowed to addresses X,Y & Z.
incoming requests to ports 23, 20 are disallowed
etc.
This should easily allow you to be as secure as you like.

>I thought that the best way to make the Iris secure and still allow network
>access would be to disable telnetd and ftpd, leaving inetd and smtpd working
>for mail to be available.  This would allow telnet and ftp *from* our Iris,
>but not *to*.

If you're worried about internal security, rather than disabling inetd as
some have suggested, you can just turn of the relevant services in inetd.conf
as you suggest.

>Can anyone comment on the security of this measure.  Is there any likelihood
>at all of an intruder when there is no telnetd or ftpd operating?

Basically you're secure (mod backdoors/bugs in the programs you're still
running e.g. sendmail bugs :-). Just run netstat -a and look what's 
istening. Nobody can connect to what's not running !

Tim
-- 
Tim Wright, Sequent Computer Systems Ltd.,        |  Email: timw@lonsqnt.co.uk
Customer Services, Allied Dunbar House,           |   or    timw@sequent.com
Chilsey Green Rd., Chertsey, Surrey, UK, KT16 9HB |  Phone: +44-932-568900
"I've got a set of teeth that druids could worship at" - Cat, Red Dwarf
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.security.misc
Subject: Re: Summary: Re: Disabling telnetd and ftpd etc
Date: 3 Sep 92 04:48:48 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <1992Sep2.150939.1@vcp1.vcp.monash.edu.au> daniel@vcp1.vcp.monash.edu.au writes:
>scott@prism.gatech.edu mentioned that there is no protection against
>IP spoofing (a machine pretending to have another's address.)  No-one
>else mentioned this.  How serious a threat is it?  Are routers told
>which machines are on the 'inside' and which are on the 'outside' of
>a subnet?

We have the packet filter on the router that connects us to NEARnet set up
to do this.  It won't forward any packet whose source address is on our
network.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.security.misc
From: frank@D012S436.sniap.mchp.sni.de ()
Subject: Re: Covert channel
Organization: Siemens-Nixdorf AG
Date: Tue, 1 Sep 92 13:12:02 GMT

jfh@rpp386.lonestar.org (John F. Haugh II) writes:
: In article <1992Aug27.080947.10737@sniap.mchp.sni.de> frank@D012S436.sniap.mchp.sni.de writes:
: >So no security policy can ever be violated, because anything you may be
: >able to do must have been "permitted".  Cracked somebody's password?  
: >Well you were able to do it weren't you?  Doesn't violate the security 
: >policy then, does it?  

: Perhaps there is a difference in the word "permit" between English and
: German, but in English the word "to permit" means that one has not only
: the ability, but also the authorization (what might be thought of as
: ``permission'').

Firstly, I'm not German, I'm Irish.  We have been speaking
English almost as long as you have, but with more success.

Secondly, if I were German, your remark would be offensive.

Thirdly, on the matter of English usage, you are not correct.

ENGLISH LESSON ON:
-----------------
"His crowbar permitted him to gain entry to the house".
"Her neural network program permitted her to modify the mail headers"
"The security policy does not permit modification of the mail headers"

You wrote:
	"a mail system which permits....must be used"   
and in the next para:
	"if you are permitted..then policy is not violated"       

In your second sentence, "permit" has no subject.  *You* may 
think "security policy" is its subject, but it isn't.  It's
enough that you "are permitted". The mail system permits you, 
so you are permitted.  Policy is not violated.  You can therefore 
you may.  You wrote that, not me.
ENGLISH LESSON OFF
------------------

Next time, if you say what you mean, I'll read what you mean.

  /
Slan leat.  Auf Wiedersehen.  (Have a good day).

: -- 
: John F. Haugh II                   | "The US Government has the Midas Muffler
: Ma Bell: (512) 251-2151            |  touch: everything they touch turns to
: UUCP: ...!cs.utexas.edu!rpp386!jfh |  shit."
: Domain: jfh@rpp386.cactus.org      |                  -- Jay Maynard
--
Frank O'Dwyer		       			Disclaimer: 
Siemens-Nixdorf AG 	                        I will deny everything
Tel.  : +49 (89) 636-40639                      Fax.  : +49 (89) 636-45860
e-mail: Frank.ODwyer@sniap.mchp.sni.de <--Use this, reply-to is broken
Newsgroups: comp.security.misc
From: smith@sctc.com (Rick Smith)
Subject: Re: Covert channel
Organization: SCTC
Date: Wed, 26 Aug 1992 20:01:40 GMT


A good way of thinking about the definition of a 'covert channel' as
opposed to other kinds of security flaws is to think in terms of
mandatory access control (MAC) concepts. The essential idea in
conventional MAC is that more sensitive stuff is absolutely kept
separate from less sensitive stuff. For example, data marked "secret"
is never visible in "unclassified" portions of the system. The secret
stuff is never, never allowed on the other side of the boundary.

Covert channels are techniques that move things across the boundary,
circumventing the security controls.

The password example is in a system without MAC. There is no MAC
boundary between the password and the unauthorized recipient.
Therefore it's not a covert channel.

Rick.
smith@sctc.com   arden hills, minnesota
Newsgroups: comp.security.misc