HDTenEightyP/NetNews huggingface dataset:
Subject: How secure is chroot? 
Distribution: world
Organization: nexnix
Date: Sun, 16 Aug 1992 20:39:47 +0000


In article <1992Aug15.093848.9784@dircon.co.uk> uaa1006@dircon.co.uk writes:
>
>I'm developing a system which uses the chroot(S) call to limit 
>the area a user can access on a UNIX system.
>
>I have a program which is SUID root, which runs chroot and then
>sets the UID of the process to that of the user, and spawns 
>/bin/sh (which is present under the chroot path).
>
>My question is....how secure is this? Are there any areas I 
>should look out for to ensure that no one can access other parts 
>of the system?
>
>General comments and observations about the chroot facility 
>would also be of interest.
>
>I should add that under the chroot area, I've created a /dev
>directory, containing entries for /dev/null, /dev/tty, /dev/socksys 
>(for outgoing ftp/telnet).
>
I haven't tried this myself (maybe I will in the next day or so),
but if a user gains root privileges, whats to stop them mknod'ing a
disk device and accessing the rest of the world via that?
(or have I overlooked something?)

Gary

Newsgroups: comp.security.misc
From: nickel@cs.tu-berlin.de (Juergen Nickelsen)
Subject: Re: Fake headers on Internet mail
Reply-To: nickel@cs.tu-berlin.de
Organization: STONE Project, Technical University of Berlin, Germany
	<1992Aug13.164814.11389@aio.jsc.nasa.gov>
Date: Thu, 13 Aug 1992 20:17:07 GMT

In article <1992Aug13.164814.11389@aio.jsc.nasa.gov>
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.  

If I remember correctly, an "Apparently-From:" or "Apparently-To:"
header is only inserted when there is no "From:" respectively "To:"
header in the "DATA" part of the mail.

SunOS' sendmail (4.1) only inserts an "Apparently-To:" header in this
case.

--
Juergen Nickelsen
Newsgroups: comp.security.misc
From: fec@cbnewsl.cb.att.com (f.e.carey)
Subject: covert channels
Organization: AT&T Bell Laboratories
Date: Thu, 20 Aug 1992 21:42:20 GMT


>I believe this definition intends -- although I see it doesn't state --
>that all system access controls and other security checks are functioning
>correctly.  In other words, process A and process B _are_ obeying all of
>the individual security rules imposed by the system, but somehow process
>A manages to send, and process B to receive, information that the overall
>system security policy would not permit to be sent directly.  (That's why
>its "surprising to the authorities" <1992Aug15.162611.24659@sctc.com> :-)

This is close to my understanding but I don't think 
the covert channel needs to involve communication
between two processes and you don't need a sender
per se.  For example:

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?

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?

Frank Carey at Bell Labs
Newsgroups: comp.security.misc
From: oved@ccu.umanitoba.ca
Subject: jhgjh
Organization: University of Manitoba, Winnipeg Manitoba Canada
Date: Thu, 13 Aug 1992 13:41:14 GMT

xxxxxxxxxxxx
From: sherer@lub001.lamar.edu
Newsgroups: comp.security.misc
Subject: Answers to Fake headers on Internet mail
Date: 12 Aug 92 14:27:58 GMT
Organization: Lamar University - Beaumont

Thank you to all of you that responded to the Fake Headers in Internet mail. I
received a number of messages within a short amount of time. 

The answers to my questions were:

	1. Yes, there is a way to fake headers in Internet mail.

	2. Most people agreed it is not possible to stop it, although 
           most of them said this subject was "trivial" and that most 
           beginners on Internet mail already know how to do it.

I guess I am a novice at this sort of thing, so that is why I posted the
message to NEWS to get the experts' advice. I was more concerned about security
issues rather than the scoop on how to actually do it. Obviously this is not of
much concern to anyone and there isn't much anyone can do about it.

Thanks for the info.

Kirk Sherer
Lamar University
Newsgroups: comp.security.misc
From: yedidya@bimacs.BITNET (Yedidya Israel)
Newsgroups: comp.security.misc
Subject: Re: SMTP SECURITY: A new (?) idea
Date: 16 Aug 92 14:48:11 GMT
Organization: Math department, Bar-Ilan University, Ramat-Gan, ISRAEL

In article <1992Aug13.102249.16853@jarvis.csri.toronto.edu> flaps@dgp.toronto.edu (Alan J Rosenthal) writes:
>kanagn@athina.cc.uch.gr (Kostas Anagnostakis) writes:
>>Why not implement SMTP allowing only connections from PRIVILEGED ports.

A better solution can be to accept SMTP connections only from trusted
hosts (and maybe limiting to a specified port too). Mail should be
bubbled like name server queries are bubbled through the net.

>1) If you start doing this on your machine, you will stop being able to
>exchange mail with people who aren't doing this.

Use MX record to point to your "forwarder", well there are still old
versions of mailer that do not care of MX but they are minority.
--
Israel Yedidya,         Phone:  972-3-5318682 or 972-3-5318407/8
System Administrator,   Fax:    972-3-5353325
Math & CS Department,   Email:  yedidya@bimacs.cs.biu.ac.il
Bar-Ilan University,    Bitnet: yedidya@bimacs
Ramat-Gan, ISRAEL.      Uucp:   ...!uunet!pucc.princeton.edu!bimacs!yedidya
If someone proves there is no God, I'll stop being religious!
From: rjq@phys.ksu.edu (Rob Quinn)
Newsgroups: comp.security.misc
Subject: Tracking mail connections ( Was Re: Fake headers on Internet mail )
Date: 14 Aug 92 19:24:13 GMT
Article-I.D.: moe.16h18tINNhin
Organization: Kansas State University
NNTP-Posting-Host: bohr.phys.ksu.edu

In <1513@lysator.liu.se> pen@lysator.liu.se (Peter Eriksson) writes:
>[sendmail patch at ftp.lysator.liu.se to add
> "(rfc931-sender: realuserid@realhostid)" lines to the mail header]

 I would like to be able to track things like this:

From daemon Fri Aug 14 14:09:25 1992
Return-Path: <Mailer-Daemon>
Received: by phys.ksu.edu (4.1/SMI-4.1)
        id AB18747; Fri, 14 Aug 92 14:09:16 CDT
Date: Fri, 14 Aug 92 14:09:16 CDT
From: Mailer-Daemon (Mail Delivery Subsystem)
Subject: Returned mail: Unable to deliver mail
Message-Id: <9208141909.AB18747@phys.ksu.edu>
To: Postmaster

   ----- Transcript of session follows -----
<<< vrfy rjj
550 rjj... User unknown
<<< quit

  ----- No message was collected -----

 I know some of these are innocent checks, I do it all of the time myself,
but about a month ago I had about a dozen of these in one day, and several
the next day. How can I tell where they came from? Do any of the public
sendmails provide better information? Anyway to log the VRFY's that succeed
too?

--
|                                                                Rob Quinn |
|                                                         rjq@phys.ksu.edu |
|                                                    QuinnBob@KSUVM.BITNET |
Newsgroups: comp.security.misc
From: mickel@OES.ORST.EDU (Paul M. Mickel)
Subject: Re: Wanted: How to setup a unix workstation for a maximum security
Keywords: security
Organization: Oregon Extension Service, Oregon State University, Corvallis, Or.
Date: Thu, 20 Aug 1992 21:23:17 GMT

In article <1992Aug16.164237.25937@reed.edu> horde@reed.edu (Mr. Heiji Horde) writes:
>Maximum security? That's easy. Don't take it out of the box. :) :) :)
>
>For something slightly less secure, take it out of the box, set it up,
>  but don't plug it into the network. :) :) :)
>
>	-Heiji
>	 "I've been hacking all night, my brain is toast."

This is especially bad at 3am, when you accidently shove a job into the back-
ground, try to kill it, and kill init instead :) :)

Seriously, I have book by the O' Reily people called "Practical Unix Security"
that is an excellent book for setting up a machine that is reasonably secure.

-pmm

-- 
Paul M. Mickel				Internet:mickel@oes.orst.edu
Oregon State University                 UUCP: ...hplabs!orstext!mickel
Corvallis, OR 97331   USA               #include <stddisclaimer.h>
Newsgroups: comp.security.misc
From: rick@tessi.com (Rick Lindsley)
Subject: Re: Secure setuid mount program - possible?
Organization: Test Systems Strategies, Inc., Beaverton, Oregon
Distribution: comp
Date: Wed, 19 Aug 1992 19:49:11 GMT

In <BUZZ.92Aug19092622@toxicavenger.bear.com> buzz@fsrg.bear.com writes:

    We wish to make mount and umount available to two or three non-root
    accounts.

Setuid issues aside, make sure that they are judicious in protection of
their accounts. Anything you base on trusting them goes out the window
if their accounts can be compromised.

Rick
From: jfh@rpp386.lonestar.org (John F. Haugh II)
Newsgroups: comp.security.misc
Subject: Re: Limiting reading of passwd to slow logins
Date: 12 Aug 92 12:41:02 GMT
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: River Parishes Programming, Austin, Republic of Texas

In article <1992Aug10.191851.4562@chg.mcd.mot.com> heiby@chg.mcd.mot.com (Ron Heiby) writes:
>jfh@rpp386.lonestar.org (John F. Haugh II) writes:
>>Next, you
>>must track and account for all authentication failures and turn off
>>any account (either permanently or for a brief period of time) that
>>exceeds the allowable number of failed trials.
>
>This means that your system is now open to a "denial of service"
>attack.  In other words, although I may not be able to be nasty to you
>by logging in on your system and accessing your data, I *can* prevent
>you from doing so by making multiple failed login attempts on your
>login id.

That's correct.  I think that any scheme which merely relies on failed
authentication counters to protect the system is going to suffer from
this deficiency.  If the only thing you have is a hammer, everything
looks like a nail ...

The approach that I prefer is one where the number of trials before
an account is locked out is large enough that the attack must last for
an extended period of time and STILL not have a reasonable probability
of success.  This differs from many systems where 3 or 5 failed trials
disables the account yet still protects you against someone who is
somewhat determined.

>I'm sure that there are ways of mitigating this risk.  For example,
>you might set up your Email system to *always* present *all* address
>information as first.last@host.dom.ain, while the actual login id used
>is non-predictable.  Some element of "denial of service" risk still
>remains, though.

The problem then is that the bad guy might get the login name of the
user that is under attack.  Using card keys which present a random ID
(really random, not predictably random) would solve this problem, but
then you could just get rid of the password and use that random value
as authentication for the user.  [ Supposing that you want to give
access only to the person who physically possesses the card ... ]
-- 
John F. Haugh II                   | Life's Little Instruction Book:
Ma Bell: (512) 251-2151            | "#138.  Learn Spanish.  In a few years,
UUCP: ...!cs.utexas.edu!rpp386!jfh |  more than 35% of all Americans will speak
Domain: jfh@rpp386.cactus.org      |  it as their first language."
From: jfh@rpp386.lonestar.org (John F. Haugh II)
Newsgroups: comp.security.misc
Subject: Re: Covert channel
Date: 21 Aug 92 13:22:50 GMT
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: River Parishes Programming, Austin, Republic of Texas

In article <1992Aug20.173003.2367@den.mmc.com> jhull@mercury.NoSubdomain.NoDomain (   Joseph F. Hull) writes:
>John is contradicting himself.  Many systems rely on procedural elements to implement 
>portions of the security policy, i.e., there may be many systems which have e-mail software 
>that allows the user to change mail headers and also have security policies which prohibit
>the transfer outside the organization of specified information.  Any user who uses fields in
>the mail header to transfer such information is violating the system security policy.  And,
>under the definition given above, such use constitutes a covert channel.
>
>The definition John quotes above is also the one I use and is, I suggest, the most 
>appropriate.  Can we agree that, for this thread, this is the one we will use?

The use of a mail header is the use of obfuscation to transport data.

If I use a simple substitution cipher, for example, replace "USSR" with
"the credenza", "nuclear missles" with "the book" and "B-52 bombers"
with "Ms. Cratchet", does the sentence

	"Please have Ms. Cratchet but the book on the credenza"

in the middle of a mail message to your wife constitute the use of a
covert channel (assuming your wife isn't "Secretary of Defense" ;-)
or something else?

Not every "unanticipated use" is a covert channel.  Not every violation of
policy requires that a covert channel be used.
-- 
John F. Haugh II                   | Life's Little Instruction Book:
Ma Bell: (512) 251-2151            | "#138.  Learn Spanish.  In a few years,
UUCP: ...!cs.utexas.edu!rpp386!jfh |  more than 35% of all Americans will speak
Domain: jfh@rpp386.cactus.org      |  it as their first language."
Newsgroups: comp.security.misc
From: gtoal@ibmpcug.co.uk (Graham Toal)
Subject: Re: Fake headers on Internet mail
Organization: The IBM PC User Group, UK.
Date: Fri, 14 Aug 1992 00:40:58 GMT

In article <1992Aug12.151404.1424@lub001.lamar.edu> sherer@lub001.lamar.edu writes:

<apparently fake mail headers>

This happened by accident on a GEC SysV unix I used some years ago - you
would send mail, log out immediately, and someone else would log in pretty
sharply behind you on the same line.  The mail you sent out appeared to
come from the person who had just logged in.  Looked like the mail program
got your terminal id first, then looked up who was logged on that terminal
to guarantee it found the 'real' user.  Strange but true.

Graham
--
From: Barrett_Jim@ial3.jsc.nasa.gov (Jim Barrett)
Newsgroups: comp.security.misc
Subject: Re: Fake headers on Internet mail
Date: 13 Aug 1992 16:48:14 GMT
Organization: Lockheed Engineering & Sciences Co.
X-Useragent: Nuntius v1.1


In article <1992Aug12.151404.1424@lub001.lamar.edu> , sherer@lub001.lamar.edu
writes:
>My question is, is there a way to masquerade as someone else in e-mail?

Any user can connect to the SMTP daemon, and feed it any data he or she sees
fit.  No root permissions are necessary:  it's simply a matter of knowing how. 
Someone at your site with more knowledge than respect has obviously discovered
the 'how'.  

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.  

Alt.security had a discussion a couple of months ago regarding this very
problem, and a new protocol that could be implemented to assist in closing this
hole.  You might try  posting there, and asking someone to forward the results
of that discussion to you.  
--
Jim Barrett                Lockheed Engineering & Sciences Co., Houston, TX
Barrett_Jim@ial3.jsc.nasa.gov                                  713-333-6103
From: hai@hpfcso.FC.HP.COM (Hai Vo-Ba)
Date: Fri, 21 Aug 1992 14:16:38 GMT
Subject: Verilog to TEGAS translator
Organization: Hewlett-Packard, Fort Collins, CO, USA
Newsgroups: comp.lsi

	Hi,

	We're looking for a PD netlist translator that can map a hierarchical
    structural Verilog netlist into TEGAS. Any pointer is much appreciated.

----
Hai  Vo-Ba                              (303)229-3874
ESL  MS55              			hai@hpeshai.fc.hp.com
Hewlett Packard Co.
3404 E. Harmony Rd.
Fort Collins, Colorado 80525-9599
Newsgroups: comp.lsi
From: eddy@einstein.et.tudelft.nl (J.G.E. Olk)
Subject: Information on Non-Treshold Logic (NTL)
Organization: Delft University of Technology, Dept. of Electrical Engineering
Date: Mon, 17 Aug 1992 16:05:04 GMT


I'm looking for information on Nontreshold Logic (NTL).
So far I have found the following literature discussing NTL in some
way or another:

- H. Mukai, T. Sudo, H.Kindo "NTL-LSI circuit design consideration"
  Rev. Elec. Commun. Lab, 21: 541-546, Sept 1973

- R. Ranfft, H.M. Rein "High-speed bipolar logic circuits with low
  power consumption for LSI - a comparison"
  IEEE J. Solid State Circuits, SC-17: 703-712, August 1982

- M. Suzuki, S. Horiguchi, T. Sudo "A 5K-gate bipolar masterslice LSI
  with a 500 ps loaded gate delay"
  IEEE J. Solid State Circuits, SC-18: 585-592, October 1983

- M. Suzuki, H. Okamoto, S. Horiguchi "Advanced 5K-gate bipolar gate
  array with a 267 ps basic gate delay"
  IEEE J. Solid State Circuits, SC-19: 1038-1040, December 1984

- H. Ichino, M. Suzuki, S. Konaka, E. Yamamoto "A 50-ps 7K-gate
  masterslice using mixed cells consisting of an NTL gate and an LCML
  macrocell"
  IEEE J. Solid State Circuits, SC-22: 202-207, April 1987

- C.Y. Wu, T.S. Wu "A new physical timing model for bipolar NTL circuits"
  Proc. 1988 Bipolar circuits technology meeting, 223-226, sept 1988

- J.S. Wang, C.Y. Wu, M.K. Tsai "CMOS nonthreshold logic (NTL) and
  cascode nontreshold logic (CNTL) for high-speed applications"
  IEEE J. Solid State Circuits, SC-24: 779-786, June 1989

- C.T. Chuang "NTL with complementary emitter-follower driver: a
  high-speed low-power push-pull logic circuit"
  IEEE J. Solid State Circuits, SC-26: 661-665, April 1991

- A. Bellouar, M.I. Elmasry "BiCMOS nonthreshold logic for high-speed
  low-power applications"
  IEEE J. Solid State Circuits, SC-26: 1165-1167, August 1991


Still, I'm looking for more articles/books/reports discussing NTL, 
especially those covering the following topics:

- principles of NTL circuit operation
- comparison of NTL with other logics
- physical timing models for NTL
- LSI scaling aspects of NTL

So please email me if you can point me to information on NTL.
I'll post a summary in a few weeks. 

Thanks,
- Eddy

-- 
\  Eddy Olk                          Section Computer Architecture         \
/  email: eddy@duteca.et.tudelft.nl  Department of Electrical Engineering  /
\  phone: +31-15-785021              Delft University of Technology        \
/                                    The Netherlands                       /
Newsgroups: comp.lsi
From: roy@mcnc.org (Subhash Chandra Roy)
Subject: VLSI Conference in India
Followup-To: comp.lsi
Summary: Information
Keywords: VLSI India
Organization: MCNC Center for Microelectronics, RTP, NC
Distribution: usa
Date: Mon, 17 Aug 1992 19:45:04 GMT
Expires: Mon, 31 Aug 1992 04:00:00 GMT

I'm interested in getting more information on the VLSI conference
that will be held in New Delhi during the first week of January.

Can anyone enlighten me on the costs of the conference (registration,
hotels,etc)?  I'll be in Mysore/Bangalore during December and am thinking
about extending my trip for the conference.

Subhash
roy@mcnc.org
"Yet another IC designer from MCNC" 


Xref: sparky comp.lsi:522 comp.lsi.cad:865 comp.lsi.testing:177
From: gaa@castle.ed.ac.uk (G Allan)
Newsgroups: comp.lsi,comp.lsi.cad,comp.lsi.testing
Subject: High Voltage CMOS -- Prototyping ?
Keywords: CMOS, Prototyping
Date: 12 Aug 92 15:23:36 GMT
Organization: Edinburgh University

High Voltage CMOS -- Prototyping ?

I'm looking for  silicon foundries  that provide a low volume
prototyping service for high voltage (>= 10 Volts) CMOS. 

I'm already aware of AMS Austria [see "Top Fabs of 1992", Semiconductor
International, Apr 92]. 

Are there any others ?

Thanks for your help.

Gerard A. Allan                              | Post:  EMF
gaa@castle.ed.ac.uk                          |        Kings Buildings
JANET:gaa@uk.ac.ed.castle                    |        University of Edinburgh
Internet:gaa%castle.ed.ac.uk@cunyvm.cuny.edu |        Edinburgh
EARN/BITNET:gaa%castle.ed.ac.uk@UKACRL       |        Scotland
UUCP:gaa%castle.ed.ac.uk@ukc.uucp            |        EH9 3JL
From: mjohnson@netcom.Netcom.COM (Mark Johnson)
Newsgroups: comp.lsi
Subject: Re: Information on Non-Treshold Logic (NTL)
Date: 17 Aug 92 20:23:26 GMT
Organization: Netcom Online Communications Service

Try Konaka, IEEE Trans. Elect. Dev., ED-36, July 1989.

Also, the Chuang paper first appeared in the VLSI Circuits
Symposium; your JSSC citation was a subsequent publication.
Newsgroups: comp.lsi
From: keithl@klic.rain.com (Keith Lofstrom)
Subject: Re: A problem for CMOS designers
Organization: Keith Lofstrom Integrated Circuits
Date: Fri, 21 Aug 1992 02:15:44 GMT


No time to SPICE it, but here is something that works for me.  Device sizes
not included - there is a tradeoff between speed, standing current, threshold
accuracy, and size that requires lots of calculation and SPICEing.  If you
want the details filled in, my fees are reasonable ;-).

Essentially an offset comparator with source followers:

;------------------------------------------------------------------------
; source followers - make M1 stronger, so ( V(1) = V(2) when IN=0.4 )

M1  VSS  IN    1    VDD  PMOS   
M2  VSS  VSS   2    VDD  PMOS      ; node 2 is static

; source follower current mirror:

M3  1    2     VDD  VDD  PMOS
M4  2    2     VDD  VDD  PMOS

; comparator:

M5  3    1     VSS  VSS  NMOS
M6  4    2     VSS  VSS  NMOS

; comparator current mirror:

M7  4    4     VDD VDD   PMOS   ; node 4 is static
M8  3    4     VDD VDD   PMOS

;  output is node 3 - for clean response, add a few more inverter stages
;------------------------------------------------------------------------

With proper device choice, the threshold is a constant times (VDD-2*VT).
Fairly process independent.  Use a stable process like the TSMC 1.2 micron
process, and you can nail the threshold down within a few tens of millivolts.

This can be tailored to any given threshold voltage less than VDD-2*VT, 
including voltages below VSS (hard to design a protection device for that,
though).

The bias rails 2 and 4 can be shared with many inputs to reduce standing
current.  This circuit DOES draw static current.  There are some devices to
peak high speed response which are left out for clarity (and competitive 
advantage).

A fun problem!  It was pretty time consuming the first time I did it on a
customer's circuit, but now it's in the toolkit.

-- 
Keith Lofstrom         keithl@klic.rain.com       Voice (503)-520-1993
KLIC --- Keith Lofstrom Integrated Circuits --- "Your Ideas in Silicon"
Design Contracting in Bipolar and CMOS - Analog, Digital, and Power ICs
Newsgroups: comp.lsi.cad