Re: [PATCH 3/4] security: capabilities patch (version 0.4.4), part 3/4: introduce new capabilities

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Alan Cox wrote:
Ar Sul, 2006-09-10 am 15:42 +0200, ysgrifennodd David Madore:
Introduce six new "regular" (=on-by-default) capabilities:

 * CAP_REG_FORK, CAP_REG_OPEN, CAP_REG_EXEC allow access to the
   fork(), open() and exec() syscalls,

CAP_REG_EXEC seems meaningless, I can do the same with mmap by hand for
most types of binary execution except setuid (which is separate it
seems)

Given the capability model is accepted as inferior to things like
SELinux policies why do we actually want to fix this anyway. It's
unfortunate we can't discard the existing capabilities model (which has
flaws) as well really.

To expand on this a little, some of the capabilities you are looking to add are of very little if any use without being able to specify objects. For example, CAP_REG_OPEN is whether the process can open any file instead of specific ones. How many applications open no files whatsoever in practice? Even if there are some as soon as they change and need to open a file they'll need this capability and will be able to open any. CAP_REG_WRITE has the same problem. For a description of why CAP_REG_EXEC is meaningless see the digsig thread on the LSM list from earlier this year.

Further, adding more capabilities would likely make existing LSM's (like SELinux) deal with them. Since most LSM's already handle these permissions on a per-object basis these will be entirely redundant and more disruptive than useful.

Additionally since dropping capabilities is entirely discretionary and applications would be modified to actually drop the capabilities I can't ever see this being used in practice. It also embeds the policy into applications spread across the filesystem instead of having a centralized policy. Since these are non-standard capabilities any application modified to take advantage of them could only do so on Linux.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux