[ On Thu, June 26, 1997 at 05:51:30 (GMT), Luke Mewburn wrote: ]
> Subject: solving various bug reports...
>
> 1. Remote access for root with empty password
> ---------------------------------------------
> 
> PR 664 is about rlogin and ftp being blocked if root has no password,
> but rsh isn't. I clarified to the user that rlogin is now like rsh in
> that it respects ~root/.rhosts. ftp was only blocked because of
> /etc/ftpusers.
> 
> The submitter (David Sharnoff) still wants the functionality of prevented
> root access if root's password is empty. I don't believe that this is
> a special case that we need to support in r{sh,login} or ftp.

Of course.  He's right.  Root access should be prevented on any ttys
that are not marked "secure", regardless of whether there's a password.
Period.  (and of course this is one place where obscurity is necessary
-- the reason for the denial should not be revealed)

> 2. su(1) uses /etc/group instead of current grouplist
> -----------------------------------------------------
> 
> PRs 792 and 2466 both mention that su(1) parses /etc/group for the
> contents of gid 0 to determine if access is permitted to root.
> If a user's primary group is 0, but they're not in /etc/groups, things
> fail.
> 
> The suggested solution is to check the users' *current* group list
> using getgroups() (both primary & supplimentary groups) for
> existance of gid 0, instead of getpwent(getuid()) and getgrgid(0).
> This is consistant with other access checks on the system...

I concur with some of the others who've commented on this and said that
it's right the way it is....

I.e. the current method of requiring membership in "wheel" as listed in
/etc/group is correct.  This is an access control mechanism unique to
su(1) and it should not be consistent with other uses of gid 0.

In fact there should be no requirement for "wheel" to be gid 0 -- it
should be possible to make it any old UID.

> 3. su(1) ignores expired password or account
> --------------------------------------------
> 
> PR 935 adds support to su(1) to notify of impending password or
> account expiry, and to prevent non-root su to expired accounts.
> 
> login(1) enforces this, and I believe the solution is sound.
> 
> However, I would also add a general #define in <pwd.h> for
> "WARNDAYS" so that login(1), su(1) and any other related programs,
> consistantly use the same grace period.

Good idea....

> 4. login(1) patch to force password change on initial login
> -----------------------------------------------------------
> 
> PR 936 adds support for a "magic" password change date to force users
> to change their passwords on initial login.
> 
> This is good. I'd also add support to su(1) for this, and ensure that
> the value for the "magic" change is
>     a) in <pwd.h>
>     b) documented in passwd(1), passwd(5), and elsewhere

another VERY good idea the rest of the world has had for nearly 2 decades....

(well, at least the SysV world!  ;-)

> 5. packet dump support in tcpdump(8)
> ------------------------------------
> 
> PR 1205 adds hex/ascii packet dumping to tcpdump(8), and telnet option
> parsing.
> 
> cgd commented that this has been brought up in the past and knocked down.
> 
> However, Solaris' snoop(1) allows this. Given that tcpdump(8) can only
> be run by root, it woudl be trivial to supply an application that can
> do this anyway. I can't see the problem with this, but this is a
> controversial issue...

It would indeed be nice if the tcpdump maintainers would accept and
distribute such a change, but if they don't and it's not too much hastle
to integrate with a pre-import script, then I'd say go for it.

Providing yet another application for this would be silly and redundant.

All the so-called security experts who don't think such a feature should
be public need to pull their heads out of the sand and look around (again)....

All the controversy surrounds myths that people need to wake up to.

> 6. inetd runs before securelevel is raised
> ------------------------------------------
> 
> PR 1323 highlights that inetd(8) and other programs are run from
> /etc/rc before securelevel is raised. Therefore, it is possible for
> users to get into a system before securelevel is raised.
> 
> This is a complicated issue, and probably deserves its own thread.
> No idea on how to solve it.

I still like a real init(1) with run-levels and only sysctl(8) control,
though of course the latter would be sufficient and least intrusive and
appears to already be supported.

Of course splitting rc into rc and rc.insecure (and rc.insecure.local)
might be good too (but I still like full run-levels best).

On the other hand what's the matter with:

	(sleep 2; inetd) &

> 7. log root login failures at a different log level
> ---------------------------------------------------
> 
> PR 2075 changes things so that root login failures are at LOG_WARNING
> instead of LOG_NOTICE.
> 
> I'm not sure if this is totally necessary, but I'm neutral either
> way... Comments?

also neutral...

> 8. changing stuff in /etc/mtree/special to be optional
> ------------------------------------------------------
> 
> PR 3663 modifies /etc/mtree/special so that a lot of directories and
> files that won't exist in every installation are "optional".
> 
> Looks like a good idea, and I can't see fault in it. I may be missing
> something obvious though.

This has been bugging me too....  The more stuff I remove from a secure
gateway machine, the more it complains!  ;-)

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>