3

To help me to prioritize security issues and be compliance with a patch-management policy, and to reduce the exposure to risk, I would like to have a list of all packages in a Linux distribution (rpm based) which need high privilege to run and which have listen(3) capabilities and therefore, possible candidates for root exploitation.

Note that I don't want to map just the installed packaged, but all the possible packages in distribution (given the packages come just from the official repositories and the package set is finite)

There is any way to get this information via RPM spec file?

There is any Distribution which provides this information?

There is any work/reseach done already in this direction?

Improve this question
12
  • 1
    This is a question for Red Hat OSs support groups, not for Security.SE I'm afraid! Your best bet is to pull source packages and parse their source code for instances of the syscall you want to detect.
    – Steve Dodier-Lazaro
    Commented Nov 24, 2016 at 10:16
  • why redhat? There is plenty of open source Linux based on RPM. it could be Fedora, but it could be as well openSUSE or Mandriva..
    – VP.
    Commented Nov 24, 2016 at 10:40
  • @SteveDL thats what I'm doing now. But maybe there is a way to, for example, from the files permissions set in the spec file to infer if the package runs as root (i.e configuration files, just being writable by root)
    – VP.
    Commented Nov 24, 2016 at 10:43
  • 2
    yes, you can look for setuid/setgid bits on binaries, but you'd also need to check for SystemD service files I suspect, as a binary might be started as uid 0 by SystemD. Or InitV. Or Upstart or whatever madness your distro is up to. So, it might be easier to filter a specific syscall you're interested in. From experience, finding about all the apps that perform a specific behaviour on a *NIX os is HARD, no matter what. It's sometimes easier to use a MAC LSM to prevent the unwanted behaviour at runtime.
    – Steve Dodier-Lazaro
    Commented Nov 24, 2016 at 10:53
  • 1
    Am tempted to say, install all the packages in a VM, check what's running as root, add all non-autostart suid/sgid bins, and there you go. It won't be perfect, but close enough.
    – Steve Dodier-Lazaro
    Commented Nov 24, 2016 at 17:12

1 Answer 1

Reset to default
2

To some extent, it is infeasible. You may run a firewall to manage such problems. If you want to do some, the comments other users have given to you are the most you can really think to do.

There are reasons why such classification is generally infeasible. Then there are a few packages which files are encouraged not to be run but with high permissions.

  1. You always need to refer to the specific system you plan to install the package into; therefore, such classification cannot be solely per-package. Examples:

    • File permissions may differ -after- the installation.
    • Even if the permissions won't change throughout the package's files, you can allow non-root users to use (some of) them by simply modifying your system groups.

  2. You cannot rely uniquely on file permissions, but you shall know specific behaviours and semantics of binaries and scripts. Examples:

    • Take a simple HTTP server. Generally, it opens a port 80. Port 80 is below 1024 and you need advanced permissions. But if you change some conf file to a high port, then you won't need advanced permissions any more. Yet, the package is the same.
    • Moreover, how will you know IF the package has got what configuration files? If more than one?
    • What if you have a service accepting input from file rather than socket? (The file may be in a remote filesystem).

  3. Finally, some package is intrinsically ambiguous by the classification you aim to do. Example:

    • If you want to make partitions your USB stick using some foo application, likely you are not gonna need any high privilege. However, the very same application foo may be used to change the partition table of the running system, which is likely a high privilege operation.

Perhaps there are other reasons, but I cannot think of them right now.

Improve this answer
2
  • please your answer doesn't make sense at all. "To help me to prioritize security issues and be compliance with a patch-management policy" has nothing to do with Firewall... beside it I'm not talking about file permissions. Some daemons need root access because of binding privileged ports, for example
    – VP.
    Commented Jan 4, 2017 at 16:31
  • A firewall (to detect the event as soon as it happens) will be really helpful to detect listening ports at runtime, the binary which opened it, and at the end read some package log to see what package it belongs to. Then... you said this could help you "to prioritize security issues and be compliance with a patch-management policy", why do you blame me? Also, I mentioned about binding privileged ports; why do you re-do this example? Looks like you have not read my answer. By the way, sorry for not being helpful.
    – NeverGoodEnough
    Commented Jan 10, 2017 at 14:34

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .