libcap-ng库旨在使具有posix功能的编程比传统的libcap库容易得多。它包括一些实用程序，可以分析所有当前正在运行的应用程序并打印出任何功能，以及是否具有开放式边界集。不带securebits“ NOROOT”标志的开放边界集将允许仅通过调用execve来扩展保留uid 0的应用程序的完整功能。

随附的实用程序旨在让管理员和开发人员从可能以太多特权运行的各种方式中发现应用程序。例如，任何调查都应该从面向网络的应用程序开始，因为它们将是入侵的主要目标。netcap程序将检查所有正在运行的应用程序并显示结果。netcap的样本输出：

ppid  pid   acct       command          type port  capabilities
1     2295  root       nasd             tcp  8000  full
2323  2383  root       dnsmasq          tcp  53    net_admin, net_raw +
1     2286  root       sshd             tcp  22    full
1     2365  root       cupsd            tcp  631   full
1     2286  root       sshd             tcp6 22    full
1     2365  root       cupsd            tcp6 631   full
2323  2383  root       dnsmasq          udp  53    net_admin, net_raw +
2323  2383  root       dnsmasq          udp  67    net_admin, net_raw +
1     2365  root       cupsd            udp  631   full

但是，假设有人成功进入您的系统并且仅具有部分功能，那么获得完全特权的下一个目标可能是什么？pscap程序将向您显示当前在系统上运行的所有具有特权的应用程序。理想情况下，所有以uid 0运行的应用都应放弃特权。有些不能出于充分的理由，如后面所述。但是很多可以。

如果由于某种原因您觉得它太难或应用程序开发人员不愿意更改，则管理员可以使用filecap设置基于文件的功能，前提是该文件系统具有扩展的属性并且内核支持基于文件系统的功能。它还可以搜索系统上具有基于文件系统功能的文件。

我认为基于文件系统功能的目的之一是允许管理员独立于应用程序开发人员的工作来控制其安全风险配置文件并丢弃系统上应用程序的特权。我怀疑放弃特权的采用率低是因为旧的API使得执行任何任务变得乏味，因此应用程序开发人员只是不使用它。您看到多少个应用程序说您必须是root用户才能使用该程序？这是因为它只需1行代码即可检查您是否是root用户。程序员可能知道需要特定的功能，但是选择了捷径。我想通过使用易于使用的API来改变它。与添加大约20行代码的补丁相比，接受3-4行补丁更容易。

作为应用程序开发人员，您可能会感兴趣大约6个用例：删除所有功能，保留一项功能，保留若干项功能，检查您是否有任何功能，检查某些功能以及在uid更改中保留功能。我将展示使用libcap-ng（现在在python中）在下面进行这些操作是多么容易：

• 1）删除所有功能
•  2）保留一项功能 
• 3）保留多项功能 
• 4）检查是否有任何功能
•  5）检查某些功能 
• 6）在uid更改中保留功能

capng_clear(CAPNG_SELECT_BOTH);
capng_apply(CAPNG_SELECT_BOTH);

capng_clear(CAPNG_SELECT_BOTH);
capng_update(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED, CAP_CHOWN);
capng_apply(CAPNG_SELECT_BOTH);

capng_clear(CAPNG_SELECT_BOTH);
capng_updatev(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED, CAP_SETUID, CAP_SETGID, -1);
capng_apply(CAPNG_SELECT_BOTH);


if (capng_have_capabilities(CAPNG_SELECT_CAPS) > CAPNG_NONE)
    do_something();

if (capng_have_capability(CAPNG_EFFECTIVE, CAP_CHOWN))
    do_something();

capng_clear(CAPNG_SELECT_BOTH);
capng_update(CAPNG_ADD, CAPNG_EFFECTIVE|CAPNG_PERMITTED, CAP_CHOWN);
if (capng_change_id(99, 99, CAPNG_DROP_SUPP_GRP | CAPNG_CLEAR_BOUNDING))
    error();

现在，这不是很简单吗？请注意，最后一个示例使用较旧的功能库需要大约60行代码。从0.6版本开始，有一个m4宏文件可帮助将libcap-ng添加到您的autotools配置系统中。在configure.ac中，添加LIBCAP_NG_PATH。然后在Makefile.am中找到链接到libcap-ng的应用程序，将$（CAPNG_LDADD）添加到其_LDADD条目中。最后，用#ifdef HAVE_LIBCAP_NG包围可选功能代码。

该库使它更加完整的一个方面是，它将边界集视为另一种功能集。采用有效，允许或可继承的相同函数也采用bounding_set。但是有时您不想触摸边界集，因此API允许您在传统功能，边界集或两者之间进行选择。需要注意的一件事，如果要更改边界集，则必须具有SETPCAP功能。即使没有SETPCAP功能，也可以随时删除传统功能。在“功能（7）”手册页中了解有关此内容的更多信息。

那么，对于仅在几行代码中使用posix功能的所有新功能，我们该怎么办？我们应该修补所有内容以最小化功能。:-)有关一些初步的补丁程序，请参见上面的链接，这些补丁程序演示了如何删除常见软件包的privs。

参见上图。有3种应用程序。第一个就像sshd，crond，xinetd或gdm。它们为各种用户生成应用程序，而您永远不知道该用户需要什么。这些可以并且应该以全部功能运行。第二种应用程序是不需要完全特权来执行其工作，但仍可以作为根uid运行的应用程序。这确实是libcap-ng的主要目标。最后一种应用是在非root帐户上运行并删除所有priv的应用。这些我们不必担心。

上图显示了Linux 2.6.26后内核的当前状况。注意黄色的守护程序。如果应用程序没有清除其边界集并保留根uid，并且对这些应用程序的任何攻击成功，则攻击者只需调用execve就可以重新获得完全特权。下图显示了我们真正想要的。

在这张照片中，我们看到边界集已被清除，因此对具有部分功能（黄色守护程序）的应用程序的攻击仍保持部分功能。有时，应用程序有合理的理由允许子进程重新获得priv，因此libcap-ng库也允许这样做。

可以使用功能创建强化系统。如果我们修补除2-3个login / cron守护程序之外的所有守护程序以删除priv，则这些以root用户身份运行的应用程序是无效的攻击目标。但是它们仍然具有uid 0，典型的系统安装允许uid做事。例如，/ bin / sh是0755，/ bin也是0755。撤防的根进程仍然可以对系统进行特洛伊木马。但是，如果我们放弃了对root的所有读/写权限，该怎么办？像这样：

echo "Hardening files..."
find / -type f -perm /00700 -a -uid 0 -exec chmod u-wrx {} \; 2>/dev/null
find / -type f -perm /00070 -a -gid 0 -exec chmod g-wrx {} \; 2>/dev/null
echo "Hardening directories..."
find / -type d -perm /00200 -a -uid 0 -exec chmod u-w {} \; 2>/dev/null
find / -type d -perm /00020 -a -gid 0 -exec chmod g-w {} \; 2>/dev/null
echo "Correcting a couple things..."
find /sbin -type f -perm /00000 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null
find /usr/sbin -type f -perm /00000 -a -uid 0 -exec chmod u+x {} \; 2>/dev/null

该系统仍然可以工作吗？（希望您首先在VM中尝试此操作。）答案大部分是肯定的。我知道的唯一问题是，如果使用了dhcp，则需要编写/etc/resolve.conf文件。系统仍然可以工作的原因是，管理员以root用户身份登录并获得了DAC_OVERRIDE功能。DAC_OVERRIDE允许读取或写入系统上的任何文件，而不管所有权或权限如何。Sshd调用pam进行身份验证，后者依次运行具有DAC_OVERRIDE的setuid帮助程序，以便它可以读取影子文件。由于使用了pam的setuid帮助程序，因此更改密码仍然有效。

任何正在运行的守护程序都不应具有DAC_OVERRIDE功能。这样，即使该守护程序受到威胁，也不会对系统造成太大影响。由于文件的权限现在为0000，因此它无法读取/ etc / shadow。由于目录权限为0005根目录，因此无法安装二进制文件。IOW，根守护程序在读取/写入文件方面被简化为普通用户。

因此，如果您想走这条强化系统之路，则需要非常小心哪些应用程序具有DAC_OVERRIDE。这些应用程序无论具有何种uid，都将能够在系统上的任何位置读取/写入文件。它们将成为系统的攻击目标。如果您为应用程序打补丁以放弃功能，而这是必需的，则您可能要考虑该应用程序是否需要重新设计。在许多情况下，要创建一个由应用程序拥有且可由其uid写入的目录，然后将其任何写入/读取操作移至该目录。发出DAC_OVERRIDE时要非常小心。