Very Computer

[ followups to comp.unix.admin ]

As far as I know, once an account's security has been breached, the
only way to re-establish it is to:

1) lock the account

2) perform an exhaustive search for trap-doors

3) change the password

4) unlock the account

5) give the new password to the authorized user (we have them show up
   in person with ID, unless we can verify their identity over the
   phone somehow).

If there's an easier way, please let me know.  This is a royal pain
for our staff, and I'd love to find something simpler.

Our standard policy is: if we suspect that an account has been used by
someone other than the account owner, we lock the account with a
notice that says, in effect, "Your account was broken into.  We locked
it to protect your files, and to protect the rest of the system.
Please come by our offices to get the account unlocked".

This has been reviewed and approved by four separate people - it's not
just some power mad sysadmin jerking people's chains.

Again, if you know of some way around this, please let me know.

              School of Engineering and Applied Science
                      University of Pennsylvania

i need the information on companies offering unix system administration class
or trainning(2 days to 1 week), in Washington or Baltimore area, hopefully
this year. the unix system i am interested is Unix system 5. Thanks in
advance.

Quote:

>>I think this is *far* too draconian -- there is no justification in the
>>world for "locking out" a student because they forgot to logoff the system.
>>Any admin who would do this deserves to be relieved of their responsibilities.

I agree!!

Quote:>If there's an easier way, please let me know.  This is a royal pain
>for our staff, and I'd love to find something simpler.

Here at suny Albany, all student accounts on the suns and sparcs (dont have
an account on the other unix machines) have a limit to the amount of time
that they allow a terminal to be idle.  This seems to work fine.  Also
even if a person does use another persons account while he is away, that
does not mean the security is breached, they require the original password
to change it to a new one.  If you want, I'll ask what the program is that
keeps track of all the idle times and pass it on to you.

I think your making alot of extra work for your staff...   :)
--

+------------------------------------------------------------------------+
|       _________                       |   William F. Laviolette Jr.    |
|((    (_)   )   )     o  /  /        ))|  State University of New York  |
|           /   /        /  /           |           at Albany            |


|   \___/______/ __(__(__(__(___/       |--------------------------------|
|                          ____/_____)  | "Common sense is genius dressed|
|         "Billy"         (   /         | in its working clothes."       |
|                         \__/          |           -Ralph Waldo Emerson |
+------------------------------------------------------------------------+

Quote:>As far as I know, once an account's security has been breached, the
>only way to re-establish it is to:

>1) lock the account

>2) perform an exhaustive search for trap-doors

>3) change the password

>4) unlock the account

>5) give the new password to the authorized user (we have them show up
>   in person with ID, unless we can verify their identity over the
>   phone somehow).

Lock the account, change protections on the home directory so that
nothing can be rwx except by owner, set the startup shell to
something other than what is in /etc/shells.

Then, look in the tmp areas for something that the user owns. Run
acctcom on the accounting files. Make sure that there was no "su" in
/var/adm/messages performed by the user. Check to see that the student
is registered with the University, then restore the account.

aka -- no easy way.

--:(  Ace
--
    Ace Stewart | Affiliation: Eastman Kodak Company, Rochester, New York

Especially because giving a notice is very simple.  We lock the
account by changing the shell to "/usr/local/etc/offsh", which is not
in /etc/shells.  It also gives the explanation of what happened and
instructions for unlocking the account.  

By the way, we don't lock accounts that have been left logged in.  We
do lock them if we suspect that they are being misused.

Here's "offsh":

#!/bin/sh

cat <<EOM

We suspect that someone has been misusing your account.  In order to
protect your mail and files, and to protect the other users of the
system, we have locked the account.  Please bring your Penn ID to Paul
Shaffer in room 156 Moore (8-2492) in order to reactivate your
account.  

Mr. Shaffer is available:

        11:00 - 12:00           Tuesday and Friday
         2:00 -  3:00           Thursday

        or by appointment.

EOM
sleep 5

              School of Engineering and Applied Science
                      University of Pennsylvania

Quote:

>Lock the account, change protections on the home directory so that
>nothing can be rwx except by owner, set the startup shell to
>something other than what is in /etc/shells.

>Then, look in the tmp areas for something that the user owns. Run
>acctcom on the accounting files. Make sure that there was no "su" in
>/var/adm/messages performed by the user. Check to see that the student
>is registered with the University, then restore the account.

>aka -- no easy way.

>--:(  Ace

 And don't forget to make sure there actually is a message telling the
 real user what happened to the account!   Syracuse University has a
 habit of closing accounts with NO message at all to the reason why.  

             Seems kinda rude, if you ask me,

                             --=--------------------------------------------.
  _          _    _____                        David Barberi                |
  \\        //   ||---\\                       -------------                |

    \\    //     ||___//                                                    |
     \\  //      ||---\\          Syracuse University Virtual Reality Lab   |
      \\//       ||    \\                 Syracuse, New York, USA           |
       \/        ||     \\            "Bringing *space to the masses"   |
                             --=--------------------------------------------'

Quote:

>>I think this is *far* too draconian -- there is no justification in
>>the world for "locking out" a student because they forgot to logoff
>>the system.  Any admin who would do this deserves to be relieved of
>>their responsibilities.

William> I agree!!

If the terminal is in area with public access there is EVERY reason to
lock the account if found idle as it now becomes necessary to check
the owners files for any possible infiltrations.  

This has *nothing* to do with an power-hungry admin or one who takes
their job too seriously - It simply is a *absolutely* necessary
precaution for information security.

Quote:>If there's an easier way, please let me know.  This is a royal pain
>for our staff, and I'd love to find something simpler.

Nah, there really isn't any *easier* or faster way. *8-(

William> Here at suny Albany, all student accounts on the suns and
William> sparcs (dont have an account on the other unix machines) have
William> a limit to the amount of time that they allow a terminal to
William> be idle.  This seems to work fine.  Also even if a person
William> does use another persons account while he is away, that does
William> not mean the security is breached, they require the original
William> password to change it to a new one.  If you want, I'll ask
William> what the program is that keeps track of all the idle times
William> and pass it on to you.

William> I think your making alot of extra work for your staff...   :)

William> William F. Laviolette Jr

First of all, this limit you are talking about is most likely shell
determined and therefore changable by the user.  Secondly, it only
takes a few seconds for a cracker to copy a program which could breach
the security of the system so even if the idle time is not changable,
any default is most likely going to be pretty high (ie, 20 - 30
minutes).  And YES, if ANYONE uses an account which was not created
for his/her usage, SECURITY HAS BEEN breached.  Granted, it might only
have been used to send a message to the accounts owner reminding
him/her to signoff before leaving, but even *that* is a security
breach.  

And finally, YOU DO NOT NEED any password on most unix machines to do
system harmful actions.  If by chance, you leave your terminal while
logged on, you are opening yourself to having *all* your files
removed.  If by chance you were logged on as root, you no longer have
*ANY* files at all.  

When it comes to system integrity, it is pretty hard to do unnecessary
*extra work*.

James

--

Signal Processing and Interpretation Lab.  Boston, Mass  (617) 353-2879
------------------------------------------------------------------------------
"But to risk we must, for the greatest hazard in life is to risk nothing.  For
the man or woman who risks nothing, has nothing, does nothing, is nothing."
        (Quote from the eulogy for the late Christa McAuliffe.)

|> >
|> > And don't forget to make sure there actually is a message telling the
|> > real user what happened to the account!   Syracuse University has a
|> > habit of closing accounts with NO message at all to the reason why.  
|> >
|> >           Seems kinda rude, if you ask me,
|>
|> Especially because giving a notice is very simple.  We lock the
|> account by changing the shell to "/usr/local/etc/offsh", which is not
|> in /etc/shells.  It also gives the explanation of what happened and
|> instructions for unlocking the account.  
|>
|> By the way, we don't lock accounts that have been left logged in.  We
|> do lock them if we suspect that they are being misused.
|>
|> Here's "offsh":

        This should actually be a C program that ignores SIGINT.
        During the 'sleep 5' below, all the user needs to do is
        hit ^C and they are logged in.

|> #!/bin/sh
|>
|> cat <<EOM
|>
|> We suspect that someone has been misusing your account.  In order to
|> protect your mail and files, and to protect the other users of the
|> system, we have locked the account.  Please bring your Penn ID to Paul
|> Shaffer in room 156 Moore (8-2492) in order to reactivate your
|> account.  
|>
|> Mr. Shaffer is available:
|>
|>   11:00 - 12:00           Tuesday and Friday
|>    2:00 -  3:00           Thursday
|>
|>   or by appointment.
|>
|> EOM
|> sleep 5

--

 Unix Systems Support                 UUCP:  ...!uunet!tekgen.bv.tek.com!mikeew
 Tektronix, Inc.                Compuserve:  73747,2304
"Fig Newton: The force required to accelerate a fig 39.37 inches/sec."--J. Hart

I took Sys Adm I & II from Motorola, and it was *excellent*!  Hands-on,
self-paced, labs, one whole system to yourself.  Call George Morrow
at 214-888-2065.  I learned a lot more than what was in the books -
they are great about answering and following up on your questions.
It is by far the best computer course I've ever attended!
--
===============================================================================
Sarah Young, Southeast Manufacturing Technology Center, Engineering,
University of South Carolina, Columbia, SC 29208

On my system (SunOS 4.1.1), hitting ^C during the sleep logs the
person out (I just tested it).  As I understand it, hitting ^C exits
from the current process and returns to the calling process.  In this
case, you exit from your login shell and return to getty (or is it
login?), which then logs you out.

The problem you mention does occur when accounts are secured or
restricted by putting special programs in the .login, .cshrc, etc.
Then ^C will get you a shell, unless it's caught and ignored.  Here,
the login shell is taking input from the file "offsh", and nothing
can make it start taking input from stdin.  I hope.  Please correct me
if I'm wrong; there's still time to fix the script.

              School of Engineering and Applied Science
                      University of Pennsylvania