Knowing how to use tools like RSBAC is just one piece of the security puzzle. The first step on the road to a more secure system is awareness. You need to be aware of the risks and weigh the benefits and costs of matching countermeasures. Do you really need a more secure system?
You may argue that many people use Linux for a hobby and/or for private use and that very few people would be interested in breaking in on such systems. You may argue that you are off-line most of the times. But nowadays even private users have a lot of valuable data stored on their systems and most of these systems are (regularly) connected to the Internet. For example in the Netherlands it is fairly common to do your banking on-line (over the Internet). The network connection is encrypted but information about your transaktions is stored unencrypted in the browser cache. Your private (e-)mail probably is stored somewhere on your Linux box, as is data about your credit cards and possibly confidential materials belonging to your clients or your employer. Your unprotected Linux system could be a worthwile target for malicious crackers. And for some virtual burglars the incentive is not even to steal your data. A fair number of people likes to break into other peoples systems "because they are there". Many of them are not even mischievous, but they may want to use your system to provide them with extra resources or to mask their identity with yours, for example by using your system to send anonymous e-mail. In that process they may intentionally weaken your security (create backdoors) which may create additional opportunities for real crackers. Accepting these risks can result in substantial damage and costs.
However, countermeasures have a price tag too and often introduce other risks. Your system may be more difficult to administer or may show signs of reduced performance. There may be a (too) steep learning curve involved. Misconfiguration of a protection system may result in a system that in fact is less secure than before, with the added risk of a user that feels he is safe and hence is more careless with private data then ever.
In the professional world you will need to weigh the risks first. Often this process of weighting risks results in a formal security policy. The security policy should be communicated and accepted before deciding about solutions, procedures and tools. In a professional environment this process is repeated regularly: am I still safe? Are there new risks? How do I counteract? But even if you are "just" a private user it does not harm to think before you act and adopt (part of) the policies companies use.
This book does not deal with security policies extensively. A handbook that is a guide to setting computer security policies and procedures for sites that have systems on the Internet is available on the Internet itself (http://www.faqs.org/rfcs/rfc1244.html) . It lists issues and factors that a site must consider when setting security policies. One of the basic approaches listed is:
look at what you are trying to protect;
look at what you need to protect it from;
determine how likely the threats are;
implement measures which will protect your assets in a cost-effective manner;
review the process continuously, and improve things every time a weakness is found.
RSBAC is just a tool - a very useful one, but nevertheless: just a tool. It was designed to help you prevent your systems from unwanted access, but in that process it may restrict the use of your system in general. You need to be willing to accept the extra administration and the sometimes steep learning curve that comes with using RSBAC. Always ask yourself: "Why do I accept putting up with restrictions - is the risk involved worth my effort?". In practice, many times the answer should be "yes", but it's your decision. Make sure it is well-considered.