Next: , Up: Security Considerations   [Contents][Index]


11.1 Levels of Risk

There are some security risks inherent in the use of find, xargs and (to a lesser extent) locate. The severity of these risks depends on what sort of system you are using:

High risk

Multi-user systems where you do not control (or trust) the other users, and on which you execute find, including areas where those other users can manipulate the filesystem (for example beneath /home or /tmp).

Medium Risk

Systems where the actions of other users can create file names chosen by them, but to which they don’t have access while find is being run. This access might include leaving programs running (shell background jobs, at or cron tasks, for example). On these sorts of systems, carefully written commands (avoiding use of ‘-print’ for example) should not expose you to a high degree of risk. Most systems fall into this category.

Low Risk

Systems to which untrusted parties do not have access, cannot create file names of their own choice (even remotely) and which contain no security flaws which might enable an untrusted third party to gain access. Most systems do not fall into this category because there are many ways in which external parties can affect the names of files that are created on your system. The system on which I am writing this for example automatically downloads software updates from the Internet; the names of the files in which these updates exist are chosen by third parties2.

In the discussion above, “risk” denotes the likelihood that someone can cause find, xargs, locate or some other program which is controlled by them to do something you did not intend. The levels of risk suggested do not take any account of the consequences of this sort of event. That is, if you operate a “low risk” type system, but the consequences of a security problem are disastrous, then you should still give serious thought to all the possible security problems, many of which of course will not be discussed here – this section of the manual is intended to be informative but not comprehensive or exhaustive.

If you are responsible for the operation of a system where the consequences of a security problem could be very important, you should do two things:

  1. Define a security policy which defines who is allowed to do what on your system.
  2. Seek competent advice on how to enforce your policy, detect breaches of that policy, and take account of any potential problems that might fall outside the scope of your policy.

Footnotes

(2)

Of course, I trust these parties to a large extent anyway, because I install software provided by them; I choose to trust them in this way, and that’s a deliberate choice


Next: , Up: Security Considerations   [Contents][Index]