Hi
The preview site has been updated. You can check it out at http://members.cox.net/tuxxer
http://members.cox.net/tuxxer/ch-intro.html#intro-audience
" Most of the threats on the Internet typically target Microsoft Windows systems. As more and more users start trying and using linux, it will become more and more important for the common user to know how to harden his or her system against these threats. "
this suggests that Linux has no security threats at present which is not true. I would prefer a guide on hardening Linux talk about Linux rather than start by a comparison with Windows
http://members.cox.net/tuxxer/ch-chapter1.html
The parts about using gpg or md5 requires more explanation. If you are explaning it in a later part refer to that
http://members.cox.net/tuxxer/sysid-and-role.html
If you are including abbrevations such as NAT it would be better to provide the expansion, explanation or a side note
http://members.cox.net/tuxxer/gui-update.html
afaik I know yum is the recommended command line program to use instead of up2date in fedora. if you have sections on both yum and up2date you probably need to explain the differences too which I would consider out of scope for this article
http://members.cox.net/tuxxer/services-gui.html
" The services that you can *safely* disable will depend upon the role of your system."
if you need to emphasise on safely use italics or what the style guide recommends.
" yum - Enable daily run of yum, a program updater. (This will depend on your environment.)"
since every service is pretty much dependant on the role of the system special emphasis for the yum deamon is unnecessary
http://members.cox.net/tuxxer/userconfig-cli.html
" Below is a list of user accounts that most Fedora Core users will want to disable."
The above wording suggests that most users of Fedora do not run the services that follows it. It would be better to say something like this
"The following are some of the services that you might want to disable in the system depending on the your requirements"
http://members.cox.net/tuxxer/ch-chapter2.html
Since this is out of scope for your document by your own admission it would be better to just drop this. Kernel recompilation or additional hardening is unnecessary for the large majority of users and worse gives the idea that the kernel requires active manual intervention to make it secure.
http://members.cox.net/tuxxer/ch-chapter3.html
I am not sure what the policy is for linking to external documents but permissions are much better explained here
http://www.tldp.org/LDP/intro-linux/html/
Either link to this document or copy and paste with attribution (The license is compatible)
http://members.cox.net/tuxxer/fssummary.html
you can mention that these program exist in fedora extras. fc4 will have extras repo enabled by default. previous versions will require more explanation or how to add the repo (steps are different between fc2 and fc3 fyi)
http://members.cox.net/tuxxer/limit-root.html
a related sshd configuration change is disable ssh1 protocol which is prone to man-in-the-middle attack
http://members.cox.net/tuxxer/ch-chapter4.html
this section seems to be redundant
http://members.cox.net/tuxxer/shells.html
this can probably be clubbed together with the section on users
http://members.cox.net/tuxxer/passwd-sec-pam-config.html
this section requires more information. if you are going to just point to external links convert this section into a note
http://members.cox.net/tuxxer/iptables-fw-config.html
it is possible to provide a port range here. More information is available in the redhat docs. redhat.com/docs. you cannot copy and paste (license restrictions) but you very well gather the information from there
I would prefer a link to the SELinux faq and guide and provide references and a bibliography.
thanks
Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
On Wed, 30 Mar 2005 22:17:12 -0800 (PST), "Rahul Sundaram" rahulsundaram@yahoo.co.in said:
http://members.cox.net/tuxxer/ch-chapter2.html
Since this is out of scope for your document by your own admission it would be better to just drop this. Kernel recompilation or additional hardening is unnecessary for the large majority of users and worse gives the idea that the kernel requires active manual intervention to make it secure.
I think that the main issue is that the specified audience ("all users") doesn't match up with the intent (a comprehensive security overview). I don't see there's anything wrong with saying that it's a detailed guide for more advanced users, and leaving the basic security stuff for another doc - 1) don't mess with the defaults without a reason, 2) run updates, 3) there is no step 3 :)
--
Stuart Ellis
On Wed, 2005-03-30 at 22:17 -0800, Rahul Sundaram wrote:
http://members.cox.net/tuxxer/gui-update.html
afaik I know yum is the recommended command line program to use instead of up2date in fedora. if you have sections on both yum and up2date you probably need to explain the differences too which I would consider out of scope for this article
Since the section is about doing GUI updates, up2date is the right utility. The up2date utility is still maintained for Fedora by Adrian Likins, and works well. The following section in the tutorial talks about using yum as a CLI update program, so I'm a little confused about your last sentence there. (I use up2date at the command line for several of my more modest FC systems that don't have a GUI, but yum works great too.)
I think putting in a link to the update-tutorial at &FDPDOCS-URL; might be a worthwhile edit.
On Wed, 2005-03-30 at 22:17 -0800, Rahul Sundaram wrote:
Hi
The preview site has been updated. You can check it out at http://members.cox.net/tuxxer
http://members.cox.net/tuxxer/ch-intro.html#intro-audience
" Most of the threats on the Internet typically target Microsoft Windows systems. As more and more users start trying and using linux, it will become more and more important for the common user to know how to harden his or her system against these threats. "
this suggests that Linux has no security threats at present which is not true. I would prefer a guide on hardening Linux talk about Linux rather than start by a comparison with Windows
Fair enough.
http://members.cox.net/tuxxer/ch-chapter1.html
The parts about using gpg or md5 requires more explanation. If you are explaning it in a later part refer to that
A detailed discussion of these utilities doesn't fall within the scope of this document. However, a glossing of how to create a gpg keypair, and how to check files with both gpg and md5sum will be added shortly.
http://members.cox.net/tuxxer/sysid-and-role.html
If you are including abbrevations such as NAT it would be better to provide the expansion, explanation or a side note
OK. Done.
http://members.cox.net/tuxxer/gui-update.html
afaik I know yum is the recommended command line program to use instead of up2date in fedora. if you have sections on both yum and up2date you probably need to explain the differences too which I would consider out of scope for this article
The only difference I need to really point out, for the scope of this document, is the fact that one is a GUI tool, and the other is a command line tool. This was mentioned on list (thanks Paul), and I would be more than happy to put in a link to the update-tutorial mentioned there.
http://members.cox.net/tuxxer/services-gui.html
" The services that you can *safely* disable will depend upon the role of your system."
if you need to emphasise on safely use italics or what the style guide recommends.
" yum - Enable daily run of yum, a program updater. (This will depend on your environment.)"
since every service is pretty much dependant on the role of the system special emphasis for the yum deamon is unnecessary
True. However, I specifically said this for yum because I can think of environments in which the user would NOT want updates to be run every night automatically. Perhaps I can make a comment here that would be a little more clear to that end.
http://members.cox.net/tuxxer/userconfig-cli.html
" Below is a list of user accounts that most Fedora Core users will want to disable."
The above wording suggests that most users of Fedora do not run the services that follows it. It would be better to say something like this
"The following are some of the services that you might want to disable in the system depending on the your requirements"
http://members.cox.net/tuxxer/ch-chapter2.html
Since this is out of scope for your document by your own admission it would be better to just drop this. Kernel recompilation or additional hardening is unnecessary for the large majority of users and worse gives the idea that the kernel requires active manual intervention to make it secure.
Fair enough. This can wait until there is a kernel doc. Then I can provide a link.
http://members.cox.net/tuxxer/ch-chapter3.html
I am not sure what the policy is for linking to external documents but permissions are much better explained here
http://www.tldp.org/LDP/intro-linux/html/
Either link to this document or copy and paste with attribution (The license is compatible)
Linked.
http://members.cox.net/tuxxer/fssummary.html
you can mention that these program exist in fedora extras. fc4 will have extras repo enabled by default. previous versions will require more explanation or how to add the repo (steps are different between fc2 and fc3 fyi)
http://members.cox.net/tuxxer/limit-root.html
a related sshd configuration change is disable ssh1 protocol which is prone to man-in-the-middle attack
Done.
http://members.cox.net/tuxxer/ch-chapter4.html
this section seems to be redundant
How so? tcp_wrappers could block a connection to a service that is open in the firewall. The default firewall utility doesn't provide the granularity to configure iptables to allow/deny a connection based on host or network. This is a measure that provides defense in depth based on Fedora's default functionality.
http://members.cox.net/tuxxer/shells.html
this can probably be clubbed together with the section on users
Makes sense.
http://members.cox.net/tuxxer/passwd-sec-pam-config.html
this section requires more information. if you are going to just point to external links convert this section into a note
I meant to be more detailed here. I got lazy, then distracted. I'll re-address this section.
http://members.cox.net/tuxxer/iptables-fw-config.html
it is possible to provide a port range here. More information is available in the redhat docs. redhat.com/docs. you cannot copy and paste (license restrictions) but you very well gather the information from there
I'll have to look into that.
I would prefer a link to the SELinux faq and guide and provide references and a bibliography.
thanks
Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Yahoo! Mail - now with 250MB free storage. Learn more. http://info.mail.yahoo.com/mail_250
Hi
True. However, I specifically said this for yum because I can think of environments in which the user would NOT want updates to be run every night automatically. Perhaps I can make a comment here that would be a little more clear to that end.
if you are only addressing audiencing similar to the roles you are using you need to change the section on audience to reflect that. I would prefer you give a better explanation of the *availability* of this deamon and let the users decide whats appropriate for them.
Regards Rahul Sundaram
__________________________________ Do you Yahoo!? Yahoo! Personals - Better first dates. More second dates. http://personals.yahoo.com
On Thu, 2005-03-31 at 08:16 -0500, Paul W. Frields wrote:
On Wed, 2005-03-30 at 22:17 -0800, Rahul Sundaram wrote:
http://members.cox.net/tuxxer/gui-update.html
afaik I know yum is the recommended command line program to use instead of up2date in fedora. if you have sections on both yum and up2date you probably need to explain the differences too which I would consider out of scope for this article
Since the section is about doing GUI updates, up2date is the right utility. The up2date utility is still maintained for Fedora by Adrian Likins, and works well. The following section in the tutorial talks about using yum as a CLI update program, so I'm a little confused about your last sentence there. (I use up2date at the command line for several of my more modest FC systems that don't have a GUI, but yum works great too.)
I think putting in a link to the update-tutorial at &FDPDOCS-URL; might be a worthwhile edit.
-- Paul W. Frields, RHCE
Is there an update tutorial? If so, I missed in at the site. I would be happy to link to it, once I knew where it was. ;-)
-Charlie
On Thu, 2005-03-31 at 10:42 +0100, Stuart Ellis wrote:
On Wed, 30 Mar 2005 22:17:12 -0800 (PST), "Rahul Sundaram" rahulsundaram@yahoo.co.in said:
http://members.cox.net/tuxxer/ch-chapter2.html
Since this is out of scope for your document by your own admission it would be better to just drop this. Kernel recompilation or additional hardening is unnecessary for the large majority of users and worse gives the idea that the kernel requires active manual intervention to make it secure.
I think that the main issue is that the specified audience ("all users") doesn't match up with the intent (a comprehensive security overview). I don't see there's anything wrong with saying that it's a detailed guide for more advanced users, and leaving the basic security stuff for another doc - 1) don't mess with the defaults without a reason, 2) run updates, 3) there is no step 3 :)
--
Stuart Ellis
Well, I think there is a little bit of both opinions here. Maybe there are some assumptions that I have made that would be beyond the most basic user. And I admit that this could be a failing of my writing. I've been using Linux off and on since '97, so some assumptions I make may be completely obscured to the most basic user. While this document isn't meant to be the end-all-be-all document to securing a Fedora system, I think that it covers a fairly broad spectrum of potential readers. And, I think that it should serve as a guide to users who are just beginning in linux, and those who maybe familiar with linux, but aren't aware of some of the security problems associated with it.
I can agree, that for the time being, the kernel hardening section could probably be left out. I do, however, believe that it has a place here, and eventually would like to see it return to this document - or perhaps be included in a larger scope, more detailed document that was perhaps more of a collaboration. I also think that before the kernel hardening section returns that there should be a kernel compilation guide.
-Charlie
Well, I think there is a little bit of both opinions here. Maybe there are some assumptions that I have made that would be beyond the most basic user. And I admit that this could be a failing of my writing. I've been using Linux off and on since '97, so some assumptions I make may be completely obscured to the most basic user. While this document isn't meant to be the end-all-be-all document to securing a Fedora system, I think that it covers a fairly broad spectrum of potential readers. And, I think that it should serve as a guide to users who are just beginning in linux, and those who maybe familiar with linux, but aren't aware of some of the security problems associated with it.
Please don't take my comment as a criticism of your text - I like it a lot.
The thing is that I support people on forums and really do see questions like "I don't like Windows and I've got these Fedora discs, what do I do now ?". Sometimes even advanced Windows users are a complete state of bewilderment because of all the new concepts they are hit with (source code vs. packages, su and root privileges etc. etc.). If you hit a newbie with a large chunk of information at once they lose confidence and give up, even though they are capable of understanding it. I feel that your guide is for people comfortable enough with Linux to have the confidence to work through it, but I also feel that it's a good overview for that audience. --
Stuart Ellis
On Thu, 2005-03-31 at 18:46 -0800, tuxxer wrote:
On Wed, 2005-03-30 at 22:17 -0800, Rahul Sundaram wrote:
http://members.cox.net/tuxxer/ch-chapter1.html
The parts about using gpg or md5 requires more explanation. If you are explaning it in a later part refer to that
A detailed discussion of these utilities doesn't fall within the scope of this document. However, a glossing of how to create a gpg keypair, and how to check files with both gpg and md5sum will be added shortly.
You can use my page on the fedoraproject.org wiki as a jumping off point to save some time if you wish:
http://www.fedoraproject.org/wiki/DocsProject/UsingGpg/CreatingKeys
http://members.cox.net/tuxxer/services-gui.html
" The services that you can *safely* disable will depend upon the role of your system."
if you need to emphasise on safely use italics or what the style guide recommends.
" yum - Enable daily run of yum, a program updater. (This will depend on your environment.)"
since every service is pretty much dependant on the role of the system special emphasis for the yum deamon is unnecessary
True. However, I specifically said this for yum because I can think of environments in which the user would NOT want updates to be run every night automatically. Perhaps I can make a comment here that would be a little more clear to that end.
Interestingly, a related thread came up on fedora-legacy-list just recently. Some people running automatic updates on production Fedora servers -- I know, I know... not a good idea! -- were recently inconvenienced by a mysql-server upgrade that killed the service without a proper restart. (Sorry, I don't remember the exact details.)
I wouldn't put anything about this in your guide; I merely thought your comment was definitely on target.
quoth Rahul:
http://members.cox.net/tuxxer/userconfig-cli.html
" Below is a list of user accounts that most Fedora Core users will want to disable."
The above wording suggests that most users of Fedora do not run the services that follows it. It would be better to say something like this
"The following are some of the services that you might want to disable in the system depending on the your requirements"
Or, in a more stylistically pleasing manner: ;-)
"Depending on your system requirements, you may want to disable some of the following services: ..."
On Fri, 2005-04-01 at 00:54 -0800, tuxxer wrote: [...snip...]
I think putting in a link to the update-tutorial at &FDPDOCS-URL; might be a worthwhile edit. -- Paul W. Frields, RHCE
Is there an update tutorial? If so, I missed in at the site. I would be happy to link to it, once I knew where it was. ;-)
"Keeping Up to Date" on http://fedora.redhat.com/docs/ IIRC. However, it is in need of some authorial and editorial lovin', in my opinion. There's nothing about up2date on it, for example, and while I was hoping to whip it into an "Audrey Hepburn" level of style, it appears to have petered out somewhere around "Li'l Kim."
At some point I started a stem-to-stern rewrite of this document, but I appear to have lost it somewhere in the wild tundra of my hard disk(s). I was going to wait to Bugzilla this issue until I had a solution ready -- because if you're not part of the solution, you're part of the precipitate -- but I may change my mind shortly just so there's a record of my concerns somewhere more accessible than the list archives.
In the meantime, what's there is usable, and any changes should maintain the URL, so a link would be appropriate.
On Fri, 01 Apr 2005 08:09:00 -0500, "Paul W. Frields" stickster@gmail.com said:
On Fri, 2005-04-01 at 00:54 -0800, tuxxer wrote: [...snip...]
I think putting in a link to the update-tutorial at &FDPDOCS-URL; might be a worthwhile edit. -- Paul W. Frields, RHCE
Is there an update tutorial? If so, I missed in at the site. I would be happy to link to it, once I knew where it was. ;-)
"Keeping Up to Date" on http://fedora.redhat.com/docs/ IIRC. However, it is in need of some authorial and editorial lovin', in my opinion. There's nothing about up2date on it, for example, and while I was hoping to whip it into an "Audrey Hepburn" level of style, it appears to have petered out somewhere around "Li'l Kim."
I noticed the same thing and wrote this, which includes up2date:
http://www.se.clara.net/fedora/software-management-en/
I posted a earlier draft but then let it slide, partly because I saw the announcement about PUP and hoped that it could be promoted instead of up2date + CLI yum for FC4.
--
Stuart Ellis
On Fri, 2005-04-01 at 14:58 +0100, Stuart Ellis wrote:
I think putting in a link to the update-tutorial at &FDPDOCS-URL; might be a worthwhile edit.
Is there an update tutorial? If so, I missed in at the site. I would be happy to link to it, once I knew where it was. ;-)
"Keeping Up to Date" on http://fedora.redhat.com/docs/ IIRC. However, it is in need of some authorial and editorial lovin', in my opinion. There's nothing about up2date on it, for example, and while I was hoping to whip it into an "Audrey Hepburn" level of style, it appears to have petered out somewhere around "Li'l Kim."
I noticed the same thing and wrote this, which includes up2date:
http://www.se.clara.net/fedora/software-management-en/
I posted a earlier draft but then let it slide, partly because I saw the announcement about PUP and hoped that it could be promoted instead of up2date + CLI yum for FC4.
Stuart, this is excellent, and looks much closer to what I wrote (and subsequently lost). It also reads very crisply and is a good example to newer writers! I would like to see this replace the current tutorial if possible, after a suitable period of public comment and editorial process. Any extra material that the original "updates" tutorial covers could and should be subsumed into this one.
I don't know what the current status of pup is... can you suggest a URL or summarize here? In any case, if pup's not ready for prime time in FC4, we can always add information about it to this document later.
Karsten, what say you?
On Fri, 01 Apr 2005 09:18:37 -0500, "Paul W. Frields" stickster@gmail.com said:
<snip kind words>
Thanks :)
Any extra material that the original "updates" tutorial covers could and should be subsumed into this one.
From memory, the current tutorial is pretty concise, and just focuses on
updates.
I don't know what the current status of pup is... can you suggest a URL or summarize here?
I haven't seen a Website announcement - there was a mail to the config tools development list in January this year, and a presentation by Paul Nasrat and Seth Vidal at FUDCON 1 (I read an extract on the Website). --
Stuart Ellis
On Wed, 2005-03-30 at 22:17 -0800, Rahul Sundaram wrote: [BIIIIG Snip]
http://members.cox.net/tuxxer/iptables-fw-config.html
it is possible to provide a port range here. More information is available in the redhat docs. redhat.com/docs.
Where? I've looked in the RH documentation, the Security guide etc. I've run a couple searches. I've tried all of the "standard" range indicators (-:;,) ....
I'll continue to google it, to see if I find anything, but if you have a specific link, that would be great!
Thanks.
On Fri, 2005-04-01 at 09:18 -0500, Paul W. Frields wrote:
I would like to see this replace the current tutorial if possible, after a suitable period of public comment and editorial process.
I've now uploaded a new version that is complete, i.e. there's no more of my own E&Os that I can see :). If it's considered a viable document I'll amend it in line with people's comments and formally propose it for submission.
FWIW, this is written as a fairly complete overview of the topic. Sections 4-7 form a walk-through of setting up up2date suitable for a new user, and I'm happy to provide that material in a self-contained form for posting somewhere linkable, if it's of use.
The source is here:
http://www.se.clara.net/fedora/software-management-en-0.4.tar.gz
On Sat, 2005-04-02 at 21:50 -0800, tuxxer wrote:
On Wed, 2005-03-30 at 22:17 -0800, Rahul Sundaram wrote: [BIIIIG Snip]
http://members.cox.net/tuxxer/iptables-fw-config.html
it is possible to provide a port range here. More information is available in the redhat docs. redhat.com/docs.
Where? I've looked in the RH documentation, the Security guide etc. I've run a couple searches. I've tried all of the "standard" range indicators (-:;,) ....
I'll continue to google it, to see if I find anything, but if you have a specific link, that would be great!
I've read the Python code to the extent I'm able, and it *doesn't* appear to be possible. Colons are recognized as a token to separate ports and protocols, but other than that, only the first series of numerals up to any non-numeral will be used as a port designator. In other words, if you enter something like 9990-9999:tcp, no error gets thrown, but what iptables will get is "--port 9990:tcp". Of course the iptables command will take ranges, but not system-config-securitylevel.
Rahul, from what source are you deriving this?
On Sun, 2005-04-03 at 14:13 +0100, Stuart Ellis wrote:
On Fri, 2005-04-01 at 09:18 -0500, Paul W. Frields wrote:
I would like to see this replace the current tutorial if possible, after a suitable period of public comment and editorial process.
I've now uploaded a new version that is complete, i.e. there's no more of my own E&Os that I can see :). If it's considered a viable document I'll amend it in line with people's comments and formally propose it for submission.
FWIW, this is written as a fairly complete overview of the topic. Sections 4-7 form a walk-through of setting up up2date suitable for a new user, and I'm happy to provide that material in a self-contained form for posting somewhere linkable, if it's of use.
The source is here:
http://www.se.clara.net/fedora/software-management-en-0.4.tar.gz
Hmm, that link's not working for me. Do you have another?
Uttered "Stuart Ellis" s.ellis@fastmail.co.uk, spake thus:
HTML:
http://www.se.clara.net/fedora/software-management-en/index.html
Dunno if it has been mentioned before, but could all those "su -c foo" lines be replaced by "sudo foo"? We should encourage the use of sudo(1) because it generates an audit trail, while "su -c" is untraceable.
Cheers
On Sun, 2005-04-03 at 13:12 -0500, Tommy Reynolds wrote:
Uttered "Stuart Ellis" s.ellis@fastmail.co.uk, spake thus:
HTML:
http://www.se.clara.net/fedora/software-management-en/index.html
Dunno if it has been mentioned before, but could all those "su -c foo" lines be replaced by "sudo foo"? We should encourage the use of sudo(1) because it generates an audit trail, while "su -c" is untraceable.
It's really a workaround for the fact that sudo isn't configured by default. I didn't think that I could safely use sudo in the example commands, since even if the Hardening Guide was up and could be linked to, there's no guarantee that the user/admin would have successfully gone through the setup beforehand.
Uttered Stuart Ellis s.ellis@fastmail.co.uk, spake thus:
It's really a workaround for the fact that sudo isn't configured by default. I didn't think that I could safely use sudo in the example commands, since even if the Hardening Guide was up and could be linked to, there's no guarantee that the user/admin would have successfully gone through the setup beforehand.
Point taken. I thought an un-configured sudo would degenerate to "su -c" but I was wrong. (I allow myself one error per year, and now I'm up to 1952 ;-)
Cheers
On Sun, 2005-04-03 at 19:37 +0100, Stuart Ellis wrote:
On Sun, 2005-04-03 at 13:12 -0500, Tommy Reynolds wrote:
Uttered "Stuart Ellis" s.ellis@fastmail.co.uk, spake thus:
HTML:
http://www.se.clara.net/fedora/software-management-en/index.html
Dunno if it has been mentioned before, but could all those "su -c foo" lines be replaced by "sudo foo"? We should encourage the use of sudo(1) because it generates an audit trail, while "su -c" is untraceable.
It's really a workaround for the fact that sudo isn't configured by default. I didn't think that I could safely use sudo in the example commands, since even if the Hardening Guide was up and could be linked to, there's no guarantee that the user/admin would have successfully gone through the setup beforehand.
I like the idea of using sudo as well, but Stuart's obviously right in the more global sense of not making assumptions when you're writing a doc. But... do I sense the need for a sudo-tutorial? :-)
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
It's really a workaround for the fact that sudo isn't configured by default. I didn't think that I could safely use sudo in the example commands, since even if the Hardening Guide was up and could be linked to, there's no guarantee that the user/admin would have successfully gone through the setup beforehand.
I like the idea of using sudo as well, but Stuart's obviously right in the more global sense of not making assumptions when you're writing a doc. But... do I sense the need for a sudo-tutorial? :-)
Ahem. Since the postulated reader has the root password anyway (or "su -c" ain't gonna work anyway) then why not a single paragraph about adding an entry to "/etc/sudoers"? That done, all that off-putting, error-prone "su -c 'quote this junk'" disappears.
You may want to add an admonition to clean up after ones self...
Cheers
(I withdraw my previous mea culpa about 1952.)
On Sun, 2005-04-03 at 15:55 -0500, Tommy Reynolds wrote:
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
It's really a workaround for the fact that sudo isn't configured by default. I didn't think that I could safely use sudo in the example commands, since even if the Hardening Guide was up and could be linked to, there's no guarantee that the user/admin would have successfully gone through the setup beforehand.
I like the idea of using sudo as well, but Stuart's obviously right in the more global sense of not making assumptions when you're writing a doc. But... do I sense the need for a sudo-tutorial? :-)
Ahem. Since the postulated reader has the root password anyway (or "su -c" ain't gonna work anyway) then why not a single paragraph about adding an entry to "/etc/sudoers"? That done, all that off-putting, error-prone "su -c 'quote this junk'" disappears.
You may want to add an admonition to clean up after ones self...
Hmm. I'd like to be able to promote sudo (or at least handle root commands nicely), and it definitely doesn't take much text to explain the basic setup:
http://members.cox.net/tuxxer/s1-chapter3-sudo.html
If all example commands use sudo I guess it means either having a boiler-plate bit of text for all tutorials that use CLI (to keep consistency), or having a standard little article that we could link to.
It's almost the sort of thing you might stick in a FAQ, or some other high-profile central document. Could the Release Notes perhaps be stretched with a "recommended post-installation configuration" section, or similar ?
On Sun, 2005-04-03 at 22:28 +0100, Stuart Ellis wrote:
On Sun, 2005-04-03 at 15:55 -0500, Tommy Reynolds wrote:
Uttered "Paul W. Frields" stickster@gmail.com, spake thus:
It's really a workaround for the fact that sudo isn't configured by default. I didn't think that I could safely use sudo in the example commands, since even if the Hardening Guide was up and could be linked to, there's no guarantee that the user/admin would have successfully gone through the setup beforehand.
I like the idea of using sudo as well, but Stuart's obviously right in the more global sense of not making assumptions when you're writing a doc. But... do I sense the need for a sudo-tutorial? :-)
Ahem. Since the postulated reader has the root password anyway (or "su -c" ain't gonna work anyway) then why not a single paragraph about adding an entry to "/etc/sudoers"? That done, all that off-putting, error-prone "su -c 'quote this junk'" disappears.
You may want to add an admonition to clean up after ones self...
Hmm. I'd like to be able to promote sudo (or at least handle root commands nicely), and it definitely doesn't take much text to explain the basic setup:
http://members.cox.net/tuxxer/s1-chapter3-sudo.html
If all example commands use sudo I guess it means either having a boiler-plate bit of text for all tutorials that use CLI (to keep consistency), or having a standard little article that we could link to.
I would like to avoid any use of boilerplates, since they add to the maintenance load for any given set of documents. That's why I mentioned a "sudo-tutorial." Said tutorial does not need to be a long expository document covering all sudo options. It merely needs to cover enough to make any references to it useful. Then everyone can link to it and maintenance is constrained to a single point for the sudo issue.
**Side note to Charles: As far as "system hardening" goes, adding an /etc/sudoers definition such as the one shown in the link above is probably not a great idea. Is it truly "hardening" a system to provide a backdoor to the root account? I would leave out the part about NOPASSWD for purposes of your guide.
It's almost the sort of thing you might stick in a FAQ, or some other high-profile central document.
Like a sudo-tutorial? ;-)
Could the Release Notes perhaps be stretched with a "recommended post-installation configuration" section, or similar ?
Hmm... There are just as many people for whom any use of sudo is ill- advised, as those for whom it may be a godsend. Therefore I would not think the Release Notes is a good place for this. The Release Notes generally answer the question, "What is this?", "Is there anything I need to know before I install it?" and "How has it changed from the last release(s)?"
All right, I'll yield....
On Sun, 2005-04-03 at 17:59 -0400, Paul W. Frields wrote:
[ big snip ]
**Side note to Charles: As far as "system hardening" goes, adding an /etc/sudoers definition such as the one shown in the link above is probably not a great idea. Is it truly "hardening" a system to provide a backdoor to the root account? I would leave out the part about NOPASSWD for purposes of your guide.
Noted. I think I stuck this in here mainly as a placeholder, and meant to get back to it. I'll add it to the "FIX ME" list.
Thanks for pointing it out.
-Charlie
On Sun, 2005-04-03 at 17:59 -0400, Paul W. Frields wrote:
Hmm... There are just as many people for whom any use of sudo is ill- advised, as those for whom it may be a godsend. Therefore I would not think the Release Notes is a good place for this. The Release Notes generally answer the question, "What is this?", "Is there anything I need to know before I install it?" and "How has it changed from the last release(s)?"
All right, I'll yield....
I'll happily say +1 to a tutorial for sudo, anyhow - it doesn't seem to get as much press as it should.
Uttered Stuart Ellis s.ellis@fastmail.co.uk, spake thus:
I'll happily say +1 to a tutorial for sudo, anyhow - it doesn't seem to get as much press as it should.
OK, I've gotten a mini-howto for sudo together. As soon as I get my CLA paperwork through, I'll share it. It's very rough, I don't like it, but it's a beginning.
Gosh, how did that attachment get there?
Cheers
-
Paul W. Frields -
Rahul Sundaram -
Stuart Ellis -
Tommy Reynolds -
tuxxer