2:04 a.m.
On Sun, 2005-01-09 at 14:48 +0000, Stuart Ellis wrote:
On Sat, 08 Jan 2005 12:00:35 -0800, "tuxxer"
<tuxxer(a)cox.net> said:
> Please feel free to make comments, constructive criticism, etc.
> Depending upon the amount of feedback I get, I'll post a final here,
> then post that to the bug tracker.
I think that it's a really useful document, so please take these as
comments rather than criticism. The points below mainly relate to Red
Hat or Linux-specific quirks.
I think that's what we're shooting for since it's meant to be FC
specific. ;-) I'll let you know when the "all-encompassing-linux"
security book comes out....maybe I'll give you an acknowledgment. ;-)
General points)
- FWIW, I handled root commands in the Installation Guide by bracketing
them with su -c. My worry with "login as root" is that it is ambiguous
and a new user may start logging in to X as root. If you move the
sections on disabling root logins and sudo to the top you could also
promote the use of sudo for admin commands throughout the rest of the
document.
- The wheel group used by sudo can also be used in a broader way - if
you put "AllowGroups wheel" in sshd_config as well as "PermitRoot
no"
you implicitly block remote logins from all accounts other than the
users you manually added to the wheel group, which mitigates the risks
of compromised service accounts (Section 1.6). This isn't specific to
wheel, but it just reduces overhead if you reuse the group rather than
create a new one.
These definitely aren't official in any way.
- You might also want to mention the role of the built-in firewall -
even enabled services like SSH are effectively closed unless the
administrator alters the default firewall settings.
I use Firestarter, so this I need to do some playing around with this
before I can speak intelligently about it.
- SMTP has a specific security role as messaging service, so I feel that
it shouldn't be disabled. Daily LogWatch log analysis, smartd disk
monitoring, SELinux context checkers, crond etc. all send mail to the
address that root is aliased to in /etc/aliases (or
/etc/postfix/aliases). The default configurations of the SMTP services
supplied with FC are to reject connections from other hosts, so they
cannot be used as relays unless the administrator changes the config. I
find LogWatch is incredibly useful as a early warning system on our
public-facing Red Hat servers.
Makes sense.
Section 1.1)
You might want to consider the role of Installation Types here - the
user can pick an Installation Type and then customise the package groups
(which ties in with role selection in 1.2). Anaconda essentially
mandates certain packages, so you don't really get the flexibility that
you mention. Even using the "Minimal" package group will install
sendmail, CUPS, SSH and NFS (and mDNS on FC3, I think).
"If you know that the system you are installing will be used as only a
webserver, then there shouldn't be any reason to install sendmail"
See above.
Mentioned. Could probably do more here, so I will look into adding more
detail. I think I really need to do some experimentation, but don't
have the facilities at the moment.
Section 1.4)
The automatic update feature of yum could be mentioned here. The
incantation would be:
su -c '/sbin/chkconfig --level 345 yum on; /sbin/service yum start'
Done.
Section 1.5.1)
<nitpick>You've listed snortd, which doesn't ship with Fedora
Core</nitpick>.
I'm running snortd, so it showed up in the list when I ran the
command. ;-)
In the GUI you have to untick the boxes on service levels 3, 4 and 5
to
really enable/disable a service. Certain key services are also active
at runlevel 2 - sendmail and SSH.
Got it.
Section 1.5.2)
I really like the idea of the serviceslist.txt. If you put an example
listing in then users will be able to copy and paste, which should give
them more confidence to do it.
Done.
Section 1.6)
Strictly IMHO, disabling service accounts is often excessive and causes
a maintenance problem. They can't login locally, and you can easily
block remote logins (see above).
Rahul mentioned something along these lines. Does anyone know for sure
if you remove a certain service that the user for that service is
removed as well? I don't remember for sure, but I believe that the user
remains.
Section 3)
I like this section (that's all).
Thanks. Nice to get a little kudos in the middle. It's the "spoonful
of sugar that makes the medicine go down". ;-)
Section 4.2)
"Then, either reboot your system, or issue the command pkill -1 sshd.
The pkill command will force sshd to re-read it's configuration file.
This will force users to login as a normal user account and then su to
root, or utilize sudo."
Are you doing this to ensure that active SSH sessions are terminated ?
If so, it's probably worth noting. The non-disruptive way to apply a
config. change in Red Hat/Fedora is:
su -c '/sbin/service sshd reload'
This would be from my Solaris background. As you know, there are 6
different ways to do just about anything, and some of them tend to be
more graceful than others. :) However, I think that it might be
valuable to kill existing connections (assuming that you have multiple
users, which I think I touched on this in the scope and intended
audience). If you have someone "unwanted" logged on while you're making
changes, booting them might be handy. Admittedly, it's unlikely,
however, possible. I think I'll mention both, with a caveat.
--
Stuart Ellis
s.ellis(a)fastmail.co.uk
Stuart,
As usual, your comments are insightful, intelligent, experienced, and
greatly appreciated. The "general points" are valid, but may require
some "re-engineering" of the doc in its entirety, so I'll save that for
another time when I have a little more time to dedicate to it. I've
commented where I was able to make "quick changes". And again, your
insights are greatly appreciated.
All, the updates made from Stuart's comments have been posted, if you
would like to check out the revisions.
Thanks.
-Charlie
--
-tuxxer
gpg: 57EB F948 76AE 25BC E340 EFA9 FAF6 E1AC F1E1 1EA1