Dear alphists,
Here follows my original question:
> Dear alpha gurus,
>
> Given a AS 4100 with Dunix 4.0d (patch 2) and sshd (1.2.25) with
> tcp_wrapper,
>
> Each time someone uses ssh to that machine (both for logging in or for
> giving a command) I get the following audit record.
>
> audit_id: 1001 ruid/euid: 0/0
> pid: 28324 ppid: 28326 cttydev: (6,6)
> event: security
> request: SEC_SETLUID (3)
> uid: 1001
> result: -1 (0xffffffff)
> ip address: 192.107.71.51 (casaccia.casaccia.enea.it)
> timestamp: Thu Aug 27 10:13:38.91 1998 MET DST
>
> ps -ale gives (among other):
>
> 8001 I 0 28326 601 0.0 44 0 0 440K event ?? 0:00.08 sshd1
> 80808001 I + 1001 28324 28326 0.0 44 0 0 512K tty ttyp6 0:00.10 tcsh
>
> So the process causing the audit record is the shell (tcsh in this
> case, but it happens the same with sh) started by the sshd daemon.
> The strange is that ,despite the above audit record, the shell works
> absolutely fine!
>
> I would really like to now if that strange behavour means a hole in
> security or not.
>
>From the replys it seems to me that it is all fine (strange isn'it?).
The started shell has its proper uid and it is properly audited.
Watching at the audit log I noticed that the ssh-made login of users is
marked by the above audit record (and not by the usual login audit
record). The logout of ssh users has no audit record so that
the only way to know when a (ssh) user logged out is to look at the log
of sshd (usually daemon.log).
Thank you very much for your help,
Long life to the our wonderfull (and usefull) mailing-list,
Emanuele
And here follows your replys:
----------------------------- John Speno <speno_at_isc.upenn.edu>:
sshd runs as root. Shen someone uses ssh to connect to the machine,
sshd starts running as root, but switches to the user using a call to
setuid. You can see this in the source code, file sshd.c.
----------------------------- Toni Harbaugh-Blackford <harbaugh_at_ncifcrf.gov>:
This is normal. Although I don't run sshd, on my system tcp wrappers
runs *without* an audit ID, (since it is started from inetd, which runs
without an audit ID). When the real user id is set for the new shell
at login, the audit id of the new process is also set to match, hence
the SEC_SETLUID record.
----------------------------- lrs <lrs0_at_yahoo.com>:
The audit record is indicating that the security syscall is returning a
result of -1, not an error of -1. Seems to be working fine.
The reason for the -1 is that the sshd daemon doesn't log in, so it gets
no auid (-1). The process it spawns (28324) starts life with an auid of
-1. With enhanced security enabled, the setluid operation should
succeed only if the auid had not been previously set.
----------------------------- Wojtek Pilorz <wpilorz_at_bdk.pl>:
It sounds me similar to a problem on an SCO UNIX machine I was working
some 2-3 years ago. I have coded a fix for that, which was to use
setluid earlier, than in original code.
I you would like to look at it, I would try to find it.
What regards security, try to find a command which would display
login user id (it might be id -a);
The log entry you quote suggests that login user id could not be set,
so you lose ability to track actions performed by users logged in
with ssh; I would suggest you try to fix this problem.
--
Emanuele Lombardi
mail: AMB-GEM-CLIM ENEA Casaccia
I-00060 S.M. di Galeria (RM) ITALY
mailto:lele_at_mantegna.casaccia.enea.it
tel +39 6 30483366 fax +39 6 30483591
This transmission was made possible by 100% recycled electrons.
Received on Fri Aug 28 1998 - 10:10:02 NZST