I got many replies and thanks very much. I have not decided how I will
open this special account. Since we
have few machines in the NIS environment , I can limit this user to 2
machines and there I may define alias
su to 'su -i'. I wanted to go through the Rsh facility. That is also
interesting one. One can always learn new
things. The folowing people replied and thanks again. Iam adding my
question at the end.
Dan Harrington
-------------------
I've not had to mess about with this myself, but I know that the Rsh
(Restricted shell) is one mechanism available to create a captive
account. It's a variant of the Bourne shell. Use 'man 1b sh' to get at
the details.
The archives for this mailing list might yield some clues too.
Schau Brian
-----------
In your global profile:
alias su='su -'
alias alias='ls -l' # to prevent users from overriding your aliases :)
Lhercaud
=========
add the program you want them to execute in /etc/shells
and specify the shell in /etc/passwd as being the captive program.
You should forbid access to "su" for those users (make sure they are not in
the system group and that the protection for su
is 4750 with owner root and group system)
James Hammett
==============
Sorry I can't give you details, I saw this somewhere, but there is a
shell you can setup which will only allow execution of a set of
predifined commands. (I think the sendmail readme might tell you
specific details. )
Frank Wortner
=============
Actually, your "captive" users should not be running the "su" command. Su
allows a user to *gain privilege*: exactly what you do not want. In fact,
the only way -- at least the only one *I* can think of -- that they could
use su to get around the restrictions you are trying to impose involve
significant problems in security proceedures. The fact that a user can use
su to assume some other identity means that the user either knows the root
password or the password of the other identity. This is a significant
problem, since it is now impossible to impose accountability. There is no
way of knowing who did what, because users are fully capable of logging in
as someone else.
My advice is to make the su command unusable by 1) making sure that users do
not share passwords with each other and 2) changing the su command to be
executable only by members of a specific group -- "system" springs to
mind -- and adding only those users who have a need for su privilege in that
group.
Example:
chgrp system /bin/su
chmod 0510 /bin/su
Then edit /etc/group and add the users who need su privilege to the system
group:
system:0:joe,fred,frank
Hope you find this helpful!
Thomas M. Payerle
=================
here is a way to create captive accounts in Unix, though
doesn't behave exactly like the VMS version (i.e., it is an entirely
different
concept but which can lead to meeting similar goals, like symlinks vs VMS
symbols):
Create a special shell program for the captive user. This can be somewhat
simple, as an account for username time which just prints the date and
exits,
to more elaborate stuff. There exist restricted shells which provide shell-
like functionality but can be limited (I do not see any in the man pages for
my Tru64 system, so might not come with system, but should bve some
available on the net).
I am not positive how secure this is (obviously depends on the "shell" being
used), in particular would check whether su user -c command goes through the
user's default shell or not. I believe it does work correctly, but for a
security matter it is definitely worth testing. Should be reasonably
securea
from actual logon attacks.
For better security, I would consider having the "restricted shell"
immediately
chroot to some (carefully) set up directory tree. At that point, even if
the
user breaks out of the shell, they are stuck in that tree. I.e., cd / will
bring them to the top of the directory tree, not to the real /; they will be
unable to access files outside the tree even if gain root access (at least
directly; there are some ways they may be able to use root access in the
chroot tree to gain root in the real tree). This chroot directory must be
set up properly (e.g. world write access to /etc would enable someone to
write their own passwd file and get root access in the chrooted tree), but
if done properly puts a eal captivity on the account.
Hoai TRAN
=========
Here is a simple .profile
trap "" 2 3
some command
exit 0
exit 0
James Sainsbury
===============
Perhaps the restricted bourne shell Rsh(1) or ksh -r ksh(1) will be
sufficient
for your purposes.
Another option is to setup a chrooted environment for each user
this is aI tried doing this a little tricky but can be done. (Can explain
further...)
Chris Parry
===========
I tried doing this a few years ago for student
accounts at a university.
Firstly I gave all users an rbash shell. Rbash is
simply a restricted bash shell. Do a man of bash for
more info.
I set ACL's on user's login files (.login, .cshrc, .profile, etc.)
giving users read-only access. The files were actually owned
by root. Actually, the users home directory is also owned by
root with rwx ACL permissions for the user (this made sure that
they couldn't simply delete & re-create the login files because
they owned the directory).
In the login file/s I specified $PATH which pointed to a
directory of binaries that students were allowed to execute
(eg. su wasn't in this directory).
Not at nice as what can be done under VMS, but it did slow
them down a bit.
My Question:
============
In VMS system it is possible to create captive accounts. With this
> account users can only execute the commands
> in the login.com file.They can not do anything else with the
> directory or files in the account. How I can do this
> in UNIX? I have put many control sequences in .cshrc file. If the
> users do a telnet or rlogin it works well.
> But when they execute 'su username' they can login without reading
> the .cshrc file. So they have then access
> to all the files in the directory which I donot want. Iam not
using
> C2 security.Iam using NIS.I just wanted to force
> the users to execute .cshrc or .login file.
>
> Whether any one is using captive accounts in UNIX and how?
>
> Thanks in advance,
> Kumar
>
Received on Wed Nov 15 2000 - 07:52:17 NZDT