On Sun, 2005-01-09 at 14:48 +0000, Stuart Ellis wrote: > On Sat, 08 Jan 2005 12:00:35 -0800, "tuxxer" <tuxxer@xxxxxxx> 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@xxxxxxxxxxxxxx > 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
Attachment:
signature.asc
Description: This is a digitally signed message part
