The 'Security Digest' Archives (TM)

Archive: About | Browse | Search | Contributions | Feedback
Site: Help | Index | Search | Contact | Notices | Changes

ARCHIVE: Unix 'Security Mailing List' - Archives (1984 - 1987)
DOCUMENT: Unix 'Security Mailing List' #34 not known (1 file, 12144 bytes)
SOURCE: http://securitydigest.org/exec/display?f=unix/archive/034.txt&t=text/plain
NOTICE: securitydigest.org recognises the rights of all third-party works.

START OF DOCUMENT


Subject:	Security Mailing List - # 34

-------

Topics:
	Admin and new people on the list
	Security problem in SVR2 crontab(1)
	Re:  Security Mailing List, # 27
	Re: Security Mailing List, # 27
	Short mod. to password checker
	security problems with lpr and tftp
	Unix Security info requested
	Here it comes...

----------------------------------------------------------------------------

Editor's corner.

Sorry for the long delay since the last posting, but life has been busy.
There was a problem recently with the sec-request and security addresses
on isis not having writable files.  This has been fixed, but if you sent
something which bounced (and haven't sent it again already) it should work
now.


Newcomers to the list since last issue:
	David Sherman (dave@lsuc)
	Bill Kennedy (bill@ssbn)
	Bob Pellegrino (bobsun!bob@primerd)
	John Ioannidis (ji@columbia)
	Rob Horn (rhorn@infinet)
	Bill Wilder (wdw@aucs)
	Bennett Todd (dukeac!bet@ecsvax)
	Ruth E. Chanell (rchannel@wsmr08.arpa)
	Peter Lamb (root@ethz)
	Juerg Wanner (jw@owf)
	Roger Merat (merat@cgeuge51.bitnet)
	Hal Schloss (woof@psivax)
	Joseph Buck (jbuck@epimass.epi.com)
	Jon Biggar (jonab@cam.unisys.com)
	Damon Scaggs (damon@upba)
	Perry Smith (pedz@bobkat)
	Bob Tracy (rct@occrsh)
	Mark Silbernagel (root@hpvcla)
	H. Morrow Long (root@yale)
	Katrina Haines (root@sandia)
	Harlan B. Braude (hbb@mtx5d)
	Andrew Sibre (andys@men1a)
	Mike Perka (mfp@cal-unix)
	Eric Lund (eric@ericsun)
	Eric S. Goldman (cope.ucsf!goldman@ucsfcgl)
	Mark Bartelt (mark@sickkids)
	Niall Mansfield (mansfiel@embl.bitnet)
	Timothy R. Giebelhaus (giebelhaus@hi-csc)
	Rahul Dhesi (bsu-cs!dhesi@iuvax)
	Oved Ben-Aroya (oved@techunix.bitnet)
	Michael McClary (michael@m-net)
	Vince Fresquez, Jr. (utep-vaxa!vince@ut-sally)

----------------------------------------------------------------------------

Date: Tue, 7 Apr 87 10:02:11 EET
From: Teemu Torma <seismo!enea!clinet.fi!tot>
Subject: Security problem in SVR2 crontab(1)

We always re-install all administrative crontab entries via crontab(1)
program when changing init state to multi-user. Those crontab entries
are in /etc/cron.d directory and we execute "su user -c 'crontab
/etc/cron.d/user" in startup script. That directory used to be
protected as 700 and I never tought where was something wrong. After
we moved from SVR2 to SVR3, I did similiar thing to /etc/rc2* script
and found out that installing failed. The reason was, of course, that
uucp, adm etc. do not have permission for their crontab entries.

In SVR2, crontab(1) which is suid root program does not check weather
user has read-permission for file given as argument.  Because
crontab(1) will print all invalid lines to stderr, it is dangerous to
give permission to use cron to normal user. If all users or some
non-administrative user has permission to use cron in SVR2, he or she
will have read-access to any file in system.

For example: if you are not root, add your login name to file
/usr/lib/cron/cron.allow. Then give command "crontab
/usr/lib/uucp/L.sys 2>&1 | grep -v '^crontab:'" and you will se your
L.sys file on your screen.

This is not very serious problem because you can restrict usage of
cron and I have never seen a system where all users have permission to
use cron. I don't know if all SVR2 versions have this problem, I have
only tested this in Motorola 8400.


----------------------------------------------------------------------------

From: Scott Larnach <seismo!mcvax!itspna.ed.ac.uk!scott>
Date: Mon, 6 Apr 87 16:04:13 GMT
Subject: Re:  Security Mailing List, # 27

I just got this issue (via uk-unix-security@ivax.doc.ic.ac.uk) and
can I suggest the following:

% diff lock.c.orig lock.c
29a30,32
> #ifdef	SIGTSTP
> 	signal (SIGTSTP, SIG_IGN);
> #endif	SIGTSTP

for Berkeley (and other) systems with job control. Otherwise you simply
walk up to the terminal and suspend the lock program.

Regards
	Scott Larnach
	Edinburgh University Computer Services


----------------------------------------------------------------------------

From: Scott Larnach <seismo!mcvax!itspna.ed.ac.uk!scott>
Date: Mon, 6 Apr 87 16:22:53 GMT
Subject: Re: Security Mailing List, # 27

You can probably ignore that last message I sent you about the lock
program. This is clearly a suite of programs *for System V*. BSD systems
don't have the password ageing field in the password file, so neither
pwadm.c nor pwexp.c will compile on those systems.

It's just that neither the note nor the programs explained their System
V specificity.

Apologies; I just thought that if there was an obvious hole I should get
a fix out quick. But perhaps at least the list could be told the lock
program, although it will compile on BSD, isn't secure.

Regards
	Scott Larnach
	Edinburgh University Computer Services


----------------------------------------------------------------------------

Date: Wed, 8 Apr 87 14:29:28 edt
From: seismo!rutgers!moss!hoh-2!whb (Win Bent)
Subject: Short mod. to password checker

Here is a small modification to the password checking program pwchkr
which improves the breaking of the GECOS field into words by changing
commas into spaces.  Our passwd file, under 4.2 BSD, uses commas to
seperate GECOS entries, vis:

whb:PASSWORD:223:20:Win Bent,11341,1277,HOME_PHONE:/ua/whb:/bin/ksh

thus the command "finger whb" produces:

Login name: whb       			In real life: Win Bent
Phone:   x 1277
, HOME_PHONE
Directory: /ua/whb                  	Shell: /bin/ksh
On since Apr  8 11:54:39 on tty16   	

Formerly, pwchkr would have tried "Bent,11341,1277,HOME_PHONE"
(one word) as a possible password - not very likely!  Now it does
what you would expect/want, checking "Bent", "11341", "1277", and
"HOME_PHONE" (four words).  The modification could be expanded for
any field seperator.

The modification is to insert the marked lines (near line 280):
	    if ((cp2 = index(cp, ';')) != NULL)
		*cp2 = '\0';

X	    /* WHBjr hack to better divide words */
X	    cp2 = cp;
X	    while ((cp2 = index(cp2, ',')) != NULL)
X		*cp2++ = ' ';

	    for (;;) {
		if ((cp2 = index(cp, ' ')) == NULL) {

Wilson H. Bent, Jr.		... ihnp4!hoh-2!whb
AT&T - Bell Laboratories	(201) 949-1277
Disclaimer: My company has not authorized me to issue a disclaimer.

P.S. Credit where it's due: from pwchkr.c:
	From: leres%ucbarpa@Berkeley (Craig Leres)
	    Modified by Seth Alford, Roger Southwick, Steve Dum, and
	    Rick Lindsley for Tektronix
	    Modified by Wilson Bent, AT&T-BL (minor mod for gecos)



----------------------------------------------------------------------------

Date: Fri, 10 Apr 87 11:45:27 EDT
From: seismo!topaz!root (Charles Hedrick)
Subject: security problems with lpr and tftp

We have just discovered that lpr and tftpd do not respect directory
protection.  In BSD Unix, in order to see a file you must first
be able to look into the directory (i.e. every directory in the
path must be protected so you can "execute" it), and then
the file must be protected so you can read it.  For this reason,
we sometimes don't bother to protect files.  We just protect
the directory.  (E.g. source distributions usually come with all
the files readable.  We don't want to change the protections on
hundreds of files, so we just protect the main source directory.)

We have just discovered that on our Pyramid and Suns, anyone can print
any of our source files using lpr.  As far as we can see, the code in
lpr is fine.  It uses access(path,R_OK) to verify that the user can
read the file.  The bug seems to be in the kernel code for the access
system call.  As far as I can tell, the kernel code for access, after
going through 50 layers of subroutines, simply calls iaccess on the
inode to verify that the protection of the file is OK.  It doesn't
check the directories at all.  This is contrary to the documentation.
Obviously the person who wrote lpr relied upon access to work as
documented.  We have seen the problem on Pyramid 4.0 and Sun 3.2.  A
quick test suggests that it is not present in Ultrix 1.2.  I have a
suspicion that it may be a result of the kernel reorganization that
took place when NFS was added.  If so, it might be present in any
implementation that has the capability to support NFS (whether or not
your site happens to use NFS or even to have the kernel configured for
it).  If so, Ultrix 2.0 should be checked.

A similar bug is present in many versions of tftpd or in.tftpd.  This
time it is not the kernel's fault.  tftpd, in the versions we have
seen, does not use access.  Instead it stat's the file and looks at
the mode.  It will let you read any file that has world read.  This is
just plain wrong, since it does not check the protecton of the
directory.  This is particularly serious, because it means that I can
steal any source file over the Arpanet from any machine that is
running one of these versions of tftpd.  This problem is present
on at least some versions of Pyramid's operating system, and is
probably also present on many other 4.2 or 4.3 systems.  The problem
does not occur on Sun 3.2.  Sun does
  setuid(-2); setgid(-2);
This assumes that -2 is a user with no special privs.  (On NFS systems
it is called "nobody".)  They should probably also do
setgroups(0,&junk), but for many purposes this protects things.  They
still attempt to stat the file and check protection, which seems a bit
odd, but it is harmless.  We believe this fix is Sun-specific,
however.

I strongly suggest that you check your tftpd, if you run it.  Try
connecting to your own machine and retrieving a file from a protected
directory.  If you have the problem, the simplest fix is to stop
running tftpd.  Most sites don't need it.  However if you have
something that uses tftpd to boot, you may.  In that case, I suggest
adding appropriate setuid, setgid, and setgroups calls.  You must wait
until the sockets have been opened.  tftpd must be able to open a
well-known socket, for which it must be root.  However once all the
sockets are open, you should change the uid etc to something safe.

I have reported these problems to both Pyramid and Sun.




----------------------------------------------------------------------------

Date: Mon 6 Apr 87 13:14:31-EDT
From: E Gordon Strong <seismo!DEEP-THOUGHT.MIT.EDU!GS>
Subject: Unix Security info requested

Could someone provide pointers to recent papers/books/etc
addressing the question of security under unix?  I am 
particularly interested in information relating to NCSC ratings
of unix-based systems.  Information on available security
software (auditing programs, security kernels, etc) or any
first-hand information on sites running "secure" installations
would be very helpful.  Any information would be appreciated.

Please reply directly as I am not a regular reader of this list.

Gordon Strong
gs%ee@mit-xx (Arpa)
gs@mit-eddie (uucp)


----------------------------------------------------------------------------

Subject: Here it comes...
Date: 19 Apr 87 14:31:26 EET (Sun)
From: seismo!mcvax!sibelius.intrin.FI!pl

A few weeks ago I noticed the following comments in UNIX-WIZARDS
Digest, written by Robert Cherry:

> When I was setting up our new system which, required a great deal of
> access security, I removed anything of 'value' and put traces on all
> processes. Then, I +advertised+ it on various Bulletin Boards in the
> greater Los Angeles area and let the hackers have at it.

I sent mail to him asking him to share his results on this
mailing list, and he promised to do so.  Then I got his mail
asking for a better address to isis, because he didn't get
through.  And finally, he sent all to me: so, here it is - from
California to Colorado, via Finland (no, Finland is NOT a state in US :-)
It's nice we have smart mailers around !

Petri Launiainen, pl@intrin.FI
Intrinsic, Ltd., Tampere, Finland

--------------- message from Robert Cherry ----------------
Basically, the creative realm of cruisers was quite broad.  After
letting the LA hackers at my system for 6 months, I got quite an
education.  The biggest lesson of all is "THERE ARE NO RULES!"
The final result was that you can not make a *useable* Unix
system secure!  I don't have the log files handy at the moment so
I'll just give you what I can from memory.  I don't think that
mentioning specific attempts and successes serves much purpose
anyway.  Instead, I'll give a conceptual point of view and
hopefully illustrate the more creative approaches which were used
on our system.  Since the purpose and scope of computer systems
varies widely, so do their configurations and structures. What I
am offering here is a lesson in awareness.

Keep in mind that many of the following methods took quite a bit
of time to implement.  We were interested in studying the methods
used to gain access and thus we made no attempt to stop persons
attempting to break in.  In the real world, many of these methods
would most likely be discovered at an infant stage but, it only
takes one person a short time to destroy years of work.

If you could put all the creative talent out there to work in a
positive direction, you could probably control the world.  Young
people were by far the most clever.  They have also attained a
level of computerese which took me by surprise.  Especially since
I was using Unix rather than MS-DOS or CP/M. They taught me to
look at the system from a totally different perspective. Believe
me, they know of more ways to use an editor than I ever dreamed
imaginable.  Any utility was subject to uses for which the
particular program was *not* designed for.  Add to this the power
of the shell and access to the compilers plus the systems ability
to do things on its own and the scope of the problem took on a
totally new level of sophistication.  If these 21st century
computer cruisers couldn't use a program or utility to perform a
given task or, if it didn't even exist, they simply created their
own.  No problem.

One interesting point is that early in the game, several cruisers
got into the system but, not one of them ever did any damage
(such as deleting files etc.).  One person even sent me a thank
you letter for "allowing him to use the system for a while."  In
the majority of cases, after access was gained, the system was
given a thorough inspection and was played around with for a
short while and then abandoned.  The challenge was over.

Once my experiment was complete and the access logs sorted out,
the entire system was powered down, all RAM erased, and all disks
were completely reformatted and the system was reinstalled.
After three months of evaluating the logs generated by people
either breaking into or attempting to break into the system, I
have come to the realization that the only way to keep any data
secure is to keep it off the system.  I also replace all critical
system files once per month from known good files which, I keep
off line.  It may be over-kill but, our systems are a lot more
secure than many government systems.

Here then is a summary of access techniques which were performed
on our system over a period of six months while we were getting
our education on computer security.  Don't ever underestimate the
creative ability of someone without formal education in such
matters.  Some of these young computer cruisers are quite
creative!!!!!  There were two young men who were truely "Unix
Wizards".  I wish I could find them.  I'd hire them in an
instant!

Super Leaks:
	Access to the C compiler and knowing what you are doing.  One
	user actually tried to write his own login program and a shell
	which his and gid of root.  Don't forget the assmebler.

	Any file which is setuid root.  Especially those where you can
	fork shell processes with the "!cmd" command structures.  (I
	knew of a system where Kermit, which had this feature, was
	setuid root!  Dumb.)

	`World' writeable system directories such as
	/usr/spool/uucppublic offer a unique way to access higher
	levels of the system.  Usually by copying various executable
	or system files and changing their attributes (owner, group,
	permissions, and, yes, setuid and sticky bits.  These
	directories also offer users a place to store large quantities
	of files at the system's expense.

	Any access to system control files (/etc/* ...) is dangerous.
	What's even worse is if they create temporary files while
	being used and which could be altered or read by another user.
	(check out vipw) Also, watch those various log files.  Many
	contain more info than necessary.

	`System' user lines in /etc/passwd with no password.  (check,
	bin, lp, news, mail, etc.) More on this later.

	Allowing users to transfer files onto the system with non-unix
	transfer utilities such as umodem, kermit, xfer, etc.  This is
	especially true when users start transferring binary
	executable files to the system.  What they would do is
	determine the cpu type, os type, etc.  Get on a system where
	they had high level priviledges (usually school computers)
	where they would compile break-'n'-enter programs.  The PD
	programs could care less where a file will be stored/retrieved
	to/from.  At least uucico makes some attempt to control file
	transfers.

	Double check all files in /usr/lib.  Make sure that this
	directory does not allow 'world' write.  Watch for cute little
	'amendments' and 'edits' to shell script files which are
	activated by cron.  Be aware they may be scattered all over
	the system.  We created a special directory where all system
	operation scripts are kept.  Access is restricted to the
	system and root only.

	Knowing the search path order used by various programs allows
	a user to potentially add a file in an earlier searched
	directory by the same name as a system file located in a later
	searched directory.  The net effect is that the system will
	act on the bogus file instead of the intended file.

	Change ALL system level passwords frequently.  This includes
	the password for mail, bin, uucp, all adm type entries, etc.
	I wrote a program which generates a random password and
	automatically changes all system level passwords once per
	month.  You don't need to know them.  Use su if you need
	access.  Of course, you *don't* want to do this with root or
	rootcsh!!

	Batton down the hatches on any command which is invoked by the
	system.  In many cases, these are cron entries.  I can't
	believe the damage that can be done with this little bugger
	(cron & crontab).

	Secure all accounting programs, files, temporary files, etc.
	Many are called by poorly written sh-script files.  If one
	gets changed properly by a vandal, the script file may not do
	what you think it is doing!!!

	Monitor all processes which access /dev/mem, /dev/kmem, etc.
	This applies to all block and char special devices.  Just
	because a file system is unmounted doesn't mean its not
	accessable!!  Especially raw file systems.  Physical access to
	memory must be controlled.

	Don't keep ANY system source files on line.  If you must,
	create a special 'compress+crypt' type program with a unique
	private key.  I call mine rootcomp and rootucomp to totally
	scramble the structure and strings in source files.

Little Leaks:
	Strip any binary files which are solid and fixed.  Also,
	restrict access to commands like 'what', 'strings', 'see',
	etc.  These are easily used to read what other files and
	programs access.  Uucp, networks, editors, accounting, and a
	multitude of other files use various files which may appear
	harmless.  Basically, don't let users read any file, binary or
	text, which they don't have a sincere need to.

	Basically, guest accounts are a bad idea.  Also, don't forget
	to change or delete the /etc/passwd entry for guest.  Add a
	complex password to this entry if you must have one.

	Limit access to critical /usr/include, various text-database
	and *lib.a files.  Should someone find a way to change one of
	these, your whole world can change.  Any idea what you can do
	if you rewrite some of the /lib/libc.a routines?!?  Change
	getpasswd() to allow any password!!

	Watchout for those seemingly 'useful' things niave admins do.
	When I set up the system for the first time, I was having some
	trouble with the ports.  I created a passwd entry for 'who'
	with no password.  The shell was set to be /bin/who  so that I
	could hook a terminal up and determine the tty name quickly.
	I forgot to remove that little jewel.  I was lucky that it
	wasn't real dangerous but, those seemingly 'safe' diagnostic
	shortcuts you build to help get a new system on line should be
	removed as soon as they are no longer required.  Don't forget
	or overlook any of them.

	Secure your dialup lines.  This can't be stressed enough.  The
	quality of telephone service doesn't help much either.  I
	remember one time when I called my work computer from my home
	computer.  I was just doing some minor maintenance on the
	system when all of the sudden, I was connected to another
	computer!  What came across my screen for the next half hour
	was surely not intended for my eyes to see.  Take advantage of
	the call-back mechanisims available.  We don't let anybody
	just login to our system.  When you login, the system verifies
	you and then disconnects.  It waits 10 seconds and then The
	System Calls You.  We also enabled the dialup password
	feature.

	Ah yes, those neet little dot-files.  .login, .profile,
	.logout, etc.  can do amazing things if they are setup
	properly.

	Watch your inittab, and all *rc files.  These should all be
	controlled as many are used by system routines rather than
	user routines.

	Limit access to debugging tools.  Most can be used as
	intelligent disassemblers.  Since many systems use the
	standard neumonic as(1) assembler, a lot of code is easily
	edited and rebuilt in this manner.  Did you know that a
	UniPlus+ 68000 System-V as(1) assembler can assemble a great
	deal of BSD4.2 DEC-VAX 11/780 assembler source files?

	Various text files (reports, data-base dumps, accounting
	files, etc.) contain sensitive information.  What good is a
	paper shreader and documentation control of printed matter if
	you leave the electronic copies of documents unprotected?  If
	certain information got into the wrong hands, you could have a
	big legal problems.

Final Word: If a computer (any computer) is to be useable for
system development and program generation, maintenance, debugging
and test, it will be vulnerable to breakin.  As distributed, many
of the default protections are too 'open' and should be
restricted.  This may require changing the mode of the file, the
owner or both.  In some cases, you may desire to move SuperUser
only files to another file system and dismount that drive
whenever the system is unattended.  Watch for directory access
permissions being too 'open' as system cruisers don't have the
same sense of privacy and respect for others files which team
members working on a project have.  Use those group passwords!

Computer burglars don't care about what you have on the system
and how it is protected.  If they can program a system, they can
get in.  If the distribution library modules and system calls
have built-in security measures, these computer wiz-kids will
simply write their own.  Basically, once they have access to the
CPU and memory, they can get in.  The OS can become a minor
obstacle to somebody with a very good concept of the system
operation.  Write a piece of code, put it in RAM, write another
program which runs in the shell/OS and let that program start the
routine in RAM.  If the system isn't using that block of memory,
the OS doesn't pay much attention to what's in it.

Remember also that yourcomputer has slave computers in it (I/O
controllers, etc.) and they can be reprogrammed to do different
things like recording logins and passwords used by legitimate
users and then playing them back to the break-in artist when a
predefined string is typed to any serial port.  The program which
was 'installed' on our system was small and resided in the
scratch-pad RAM area of the dialup serial port controller board
which is 8086 based and has 128 K of RAM.

If the system must have a high degree of security, limit access
from dialup lines to business hours only.  Shut them down
otherwise.  Watch out for the lunch hour also.  Put critical and
private data and databases on their own file systems and unmount
them whenever they are not being used.  Power down drives or
remove disk packs over weekends and holidays - especially if the
system will be 'unattended'.

My experiment with the California Wiz Kids clearly illustrated
that the system's worst enemies are its self and careless users.
It was generally easier for the system to create its own accesses
than it was for the hackers.  All the hackers had to do was set
the trap which, I found was basically easy to do.  The ability of
unix to trap and ignore signals and errors should not be
overlooked.  The ability for users with access to the compilers,
and either a good reference library or an good understanding of
the environment, opens up a world of opportunity.  By not using
the system calls and general libraries, high-level users found it
easy to bypass the built in security measures.  One user uploaded
his source files using only the editor.  He had a simple but,
effective shell type program which gave him access to things the
csh and sh would not have given him have access to.

Check the 'create' and/or 'modifiy' dates on critical files.
Check them on a regular basis.  If one changes, check it
immediately.  If there are distribution files which are never or
rarely used, get them off the system.  They won't be missed.
Keep system sources including system reconfiguration files off
line.  You can get them back onto the system if you need to.  If
its not there it can't be abused.

Developers often leave sources unprotected in their home
directories while they are working on a project.  They often
don't consider the programs they are working on as being "useable
by others".  System cruisers will find these files in time.  In
our case, one developer was working on the satellite
communications and network gateway code and left it in his
directory with mode 0666.  Use that umask command!  In many cases
I found where programs could be edited or atleast read by
anybody.  Various a.out and core files lying around can also be a
problem area.  Just because a program still has a few bugs
doesn't mean it can't be used.  Watch those permissions!!

Remember that Read permission implies Copy permission.  Once
copied, it is a simple task to chown and edit the file.  Binary
files are not secure if the debugger can generate an assembler
output.  Once disassembled, it becomes an easy task to change the
names of various support files.  Unix has a lot of these kinds of
files.  Beware.

Last, but not least, are the on-line manuals really a good idea?
They were one of the first places many cruisers went.  Help, man,
and other user-friendly system operation and information programs
really help the cruisers.  Its a heck of a good place to get
ideas from.

Sleep well tonight!  There is always another way in and its
easier than you may think.  It's just that it takes a 12 year old
kid to figure it out! :)

Robert
 Cherry Systems Admin for anb02 B.C. & Zot

       /|	       PUP/GV : Cherry.XSIS
   `o_O'		  XNS : Robert Cherry:XSIS:Xerox
     ( )  Aachk! Phfut!  ARPA |
rocksanne!anb02!cherry%rochester:ARPA:Xerox
      U			: rocksanne!bob
			: cherry.xsis@Xerox.COM
			| cherry@anb02.CTS.COM
			UUCP : rocksanne!bob
       :=work, |=home	| {rocksanne | gryphon |
wright}!anb02!cherry

			TPC : (818) 351-2351 Ext. 2098
			XPC : 8 * 844-2098


----------------------------------------------------------------------------

                        The UNIX Security Mailing List

                 Ignore the headers on this list and mail to:
                  ...!hao!isis!security (mail for the list).
                  ...!hao!isis!sec-request (administrativia).

END OF DOCUMENT