According to https://access.redhat.com/solutions/2117321 this article,
I want to ask, how to make NFS support the penetration of Linux
Capabilities
[ This question comes up on occasion, so I've added a few interested
parties to the Cc: list ]
> On Sep 8, 2022, at 8:27 AM, battery dude <[email protected]> wrote:
>
> According to https://access.redhat.com/solutions/2117321 this article,
> I want to ask, how to make NFS support the penetration of Linux
> Capabilities
That link is access-limited, so I was able to view only the top
few paragraphs of it. Not very open, Red Hat.
TL;DR: I looked into this while trying to figure out how to enable
IMA on NFS files. It's difficult for many reasons.
A few of these reasons include:
The NFS protocol is a standard, and is implemented on a wide variety
of OS platforms. Each OS implements its own flavor of capabilities.
There's no way to translate amongst the variations to ensure
interoperation. On Linux, capabilities(7) says:
> No standards govern capabilities, but the Linux capability implementation is based on the withdrawn POSIX.1e draft standard; see ⟨https://archive.org/details/posix_1003.1e-990310⟩.
I'm not sure how closely other implementations come to implementing
POSIX.1e, but there are enough differences that interoperability
could be a nightmare. Anything Linux has done differently than
POSIX.1e would be encumbered by GPL, making it nearly impossible to
standardize those differences. (Let alone the possible problems
trying to cite a withdrawn POSIX standard in an Internet RFC!)
The NFSv4 WG could invent our own capabilities scheme, just as was
done with NFSv4 ACLs. I'm not sure everyone would agree that effort
was 100% successful.
Currently, an NFS server bases its access control choices on the
RPC user that makes each request. We'd have to figure out a way to
enable NFS clients and servers to communicate more than just user
identity to enable access control via capabilities.
When sending an NFS request, a client would have to provide a set
of capabilities to the server so the server can make appropriate
access control choices for that request.
The server would have to report the updated capset when a client
accesses and executes a file with capabilities, and the server
would have to trust that its clients all respect those capsets
correctly.
Because capabilities are security-related, setting and retrieving
capabilities should be done only over networks that ensure
integrity of communication. So, protection via RPC-with-TLS or
RPCSEC GSS with an integrity service ought to be a requirement
both for setting and updating capabilities and for transmitting
any protected file content. We have implementations, but there
is always an option of not deploying this kind of protection
when NFS is actually in use, making capabilities just a bit of
security theater in those cases.
Given these enormous challenges, who would be willing to pay for
standardization and implementation? I'm not saying it can't or
shouldn't be done, just that it would be a mighty heavy lift.
But maybe other folks on the Cc: list have ideas that could
make this easier than I believe it to be.
--
Chuck Lever
On Thu, 2022-09-08 at 20:24 +0000, Chuck Lever III wrote:
> [ This question comes up on occasion, so I've added a few interested
> parties to the Cc: list ]
>
> > On Sep 8, 2022, at 8:27 AM, battery dude <[email protected]> wrote:
> >
> > According to https://access.redhat.com/solutions/2117321 this article,
> > I want to ask, how to make NFS support the penetration of Linux
> > Capabilities
>
> That link is access-limited, so I was able to view only the top
> few paragraphs of it. Not very open, Red Hat.
>
> TL;DR: I looked into this while trying to figure out how to enable
> IMA on NFS files. It's difficult for many reasons.
>
>
> A few of these reasons include:
>
> The NFS protocol is a standard, and is implemented on a wide variety
> of OS platforms. Each OS implements its own flavor of capabilities.
> There's no way to translate amongst the variations to ensure
> interoperation. On Linux, capabilities(7) says:
>
> > No standards govern capabilities, but the Linux capability implementation is based on the withdrawn POSIX.1e draft standard; see ⟨https://archive.org/details/posix_1003.1e-990310⟩.
>
> I'm not sure how closely other implementations come to implementing
> POSIX.1e, but there are enough differences that interoperability
> could be a nightmare. Anything Linux has done differently than
> POSIX.1e would be encumbered by GPL, making it nearly impossible to
> standardize those differences. (Let alone the possible problems
> trying to cite a withdrawn POSIX standard in an Internet RFC!)
>
> The NFSv4 WG could invent our own capabilities scheme, just as was
> done with NFSv4 ACLs. I'm not sure everyone would agree that effort
> was 100% successful.
>
>
> Currently, an NFS server bases its access control choices on the
> RPC user that makes each request. We'd have to figure out a way to
> enable NFS clients and servers to communicate more than just user
> identity to enable access control via capabilities.
>
> When sending an NFS request, a client would have to provide a set
> of capabilities to the server so the server can make appropriate
> access control choices for that request.
>
> The server would have to report the updated capset when a client
> accesses and executes a file with capabilities, and the server
> would have to trust that its clients all respect those capsets
> correctly.
>
>
> Because capabilities are security-related, setting and retrieving
> capabilities should be done only over networks that ensure
> integrity of communication. So, protection via RPC-with-TLS or
> RPCSEC GSS with an integrity service ought to be a requirement
> both for setting and updating capabilities and for transmitting
> any protected file content. We have implementations, but there
> is always an option of not deploying this kind of protection
> when NFS is actually in use, making capabilities just a bit of
> security theater in those cases.
>
>
> Given these enormous challenges, who would be willing to pay for
> standardization and implementation? I'm not saying it can't or
> shouldn't be done, just that it would be a mighty heavy lift.
> But maybe other folks on the Cc: list have ideas that could
> make this easier than I believe it to be.
>
>
I'm not disputing anything you wrote above, and I clearly haven't
thought through the security implications, but I wonder if we could
piggyback this info onto security label support somehow? That already
requires a (semi-opaque) per-inode attribute, which is mostly what's
required for file capabilities.
--
Jeff Layton <[email protected]>
> On Sep 8, 2022, at 5:03 PM, Jeff Layton <[email protected]> wrote:
>
> On Thu, 2022-09-08 at 20:24 +0000, Chuck Lever III wrote:
>> [ This question comes up on occasion, so I've added a few interested
>> parties to the Cc: list ]
>>
>>> On Sep 8, 2022, at 8:27 AM, battery dude <[email protected]> wrote:
>>>
>>> According to https://access.redhat.com/solutions/2117321 this article,
>>> I want to ask, how to make NFS support the penetration of Linux
>>> Capabilities
>>
>> That link is access-limited, so I was able to view only the top
>> few paragraphs of it. Not very open, Red Hat.
>>
>> TL;DR: I looked into this while trying to figure out how to enable
>> IMA on NFS files. It's difficult for many reasons.
>>
>>
>> A few of these reasons include:
>>
>> The NFS protocol is a standard, and is implemented on a wide variety
>> of OS platforms. Each OS implements its own flavor of capabilities.
>> There's no way to translate amongst the variations to ensure
>> interoperation. On Linux, capabilities(7) says:
>>
>>> No standards govern capabilities, but the Linux capability implementation is based on the withdrawn POSIX.1e draft standard; see ⟨https://archive.org/details/posix_1003.1e-990310⟩.
>>
>> I'm not sure how closely other implementations come to implementing
>> POSIX.1e, but there are enough differences that interoperability
>> could be a nightmare. Anything Linux has done differently than
>> POSIX.1e would be encumbered by GPL, making it nearly impossible to
>> standardize those differences. (Let alone the possible problems
>> trying to cite a withdrawn POSIX standard in an Internet RFC!)
>>
>> The NFSv4 WG could invent our own capabilities scheme, just as was
>> done with NFSv4 ACLs. I'm not sure everyone would agree that effort
>> was 100% successful.
>>
>>
>> Currently, an NFS server bases its access control choices on the
>> RPC user that makes each request. We'd have to figure out a way to
>> enable NFS clients and servers to communicate more than just user
>> identity to enable access control via capabilities.
>>
>> When sending an NFS request, a client would have to provide a set
>> of capabilities to the server so the server can make appropriate
>> access control choices for that request.
>>
>> The server would have to report the updated capset when a client
>> accesses and executes a file with capabilities, and the server
>> would have to trust that its clients all respect those capsets
>> correctly.
>>
>>
>> Because capabilities are security-related, setting and retrieving
>> capabilities should be done only over networks that ensure
>> integrity of communication. So, protection via RPC-with-TLS or
>> RPCSEC GSS with an integrity service ought to be a requirement
>> both for setting and updating capabilities and for transmitting
>> any protected file content. We have implementations, but there
>> is always an option of not deploying this kind of protection
>> when NFS is actually in use, making capabilities just a bit of
>> security theater in those cases.
>>
>>
>> Given these enormous challenges, who would be willing to pay for
>> standardization and implementation? I'm not saying it can't or
>> shouldn't be done, just that it would be a mighty heavy lift.
>> But maybe other folks on the Cc: list have ideas that could
>> make this easier than I believe it to be.
>>
>>
>
> I'm not disputing anything you wrote above, and I clearly haven't
> thought through the security implications, but I wonder if we could
> piggyback this info onto security label support somehow? That already
> requires a (semi-opaque) per-inode attribute, which is mostly what's
> required for file capabilities.
That was the starting idea for accessing IMA metadata on NFS until
we discovered that NFSv4 security labels are intended to enable only
a single label per file. Capabilities are often present with SELinux
labels.
It would work for a proof of concept, though.
--
Chuck Lever
On Thu, 2022-09-08 at 21:17 +0000, Chuck Lever III wrote:
>
> > On Sep 8, 2022, at 5:03 PM, Jeff Layton <[email protected]> wrote:
> >
> > On Thu, 2022-09-08 at 20:24 +0000, Chuck Lever III wrote:
> > > [ This question comes up on occasion, so I've added a few interested
> > > parties to the Cc: list ]
> > >
> > > > On Sep 8, 2022, at 8:27 AM, battery dude <[email protected]> wrote:
> > > >
> > > > According to https://access.redhat.com/solutions/2117321 this article,
> > > > I want to ask, how to make NFS support the penetration of Linux
> > > > Capabilities
> > >
> > > That link is access-limited, so I was able to view only the top
> > > few paragraphs of it. Not very open, Red Hat.
> > >
> > > TL;DR: I looked into this while trying to figure out how to enable
> > > IMA on NFS files. It's difficult for many reasons.
> > >
> > >
> > > A few of these reasons include:
> > >
> > > The NFS protocol is a standard, and is implemented on a wide variety
> > > of OS platforms. Each OS implements its own flavor of capabilities.
> > > There's no way to translate amongst the variations to ensure
> > > interoperation. On Linux, capabilities(7) says:
> > >
> > > > No standards govern capabilities, but the Linux capability implementation is based on the withdrawn POSIX.1e draft standard; see ⟨https://archive.org/details/posix_1003.1e-990310⟩.
> > >
> > > I'm not sure how closely other implementations come to implementing
> > > POSIX.1e, but there are enough differences that interoperability
> > > could be a nightmare. Anything Linux has done differently than
> > > POSIX.1e would be encumbered by GPL, making it nearly impossible to
> > > standardize those differences. (Let alone the possible problems
> > > trying to cite a withdrawn POSIX standard in an Internet RFC!)
> > >
> > > The NFSv4 WG could invent our own capabilities scheme, just as was
> > > done with NFSv4 ACLs. I'm not sure everyone would agree that effort
> > > was 100% successful.
> > >
> > >
> > > Currently, an NFS server bases its access control choices on the
> > > RPC user that makes each request. We'd have to figure out a way to
> > > enable NFS clients and servers to communicate more than just user
> > > identity to enable access control via capabilities.
> > >
> > > When sending an NFS request, a client would have to provide a set
> > > of capabilities to the server so the server can make appropriate
> > > access control choices for that request.
> > >
> > > The server would have to report the updated capset when a client
> > > accesses and executes a file with capabilities, and the server
> > > would have to trust that its clients all respect those capsets
> > > correctly.
> > >
> > >
> > > Because capabilities are security-related, setting and retrieving
> > > capabilities should be done only over networks that ensure
> > > integrity of communication. So, protection via RPC-with-TLS or
> > > RPCSEC GSS with an integrity service ought to be a requirement
> > > both for setting and updating capabilities and for transmitting
> > > any protected file content. We have implementations, but there
> > > is always an option of not deploying this kind of protection
> > > when NFS is actually in use, making capabilities just a bit of
> > > security theater in those cases.
> > >
> > >
> > > Given these enormous challenges, who would be willing to pay for
> > > standardization and implementation? I'm not saying it can't or
> > > shouldn't be done, just that it would be a mighty heavy lift.
> > > But maybe other folks on the Cc: list have ideas that could
> > > make this easier than I believe it to be.
> > >
> > >
> >
> > I'm not disputing anything you wrote above, and I clearly haven't
> > thought through the security implications, but I wonder if we could
> > piggyback this info onto security label support somehow? That already
> > requires a (semi-opaque) per-inode attribute, which is mostly what's
> > required for file capabilities.
>
> That was the starting idea for accessing IMA metadata on NFS until
> we discovered that NFSv4 security labels are intended to enable only
> a single label per file. Capabilities are often present with SELinux
> labels.
>
> It would work for a proof of concept, though.
>
Yeah, that why I was saying "piggyback".
You'd need a combined SELinux+capabilities label (potentially with other
stuff in it as well). When you got one from the server, you'd have to
extract each piece and put in the right places in the inode.
But, like I said...I haven't thought through the implications here at
all (and am not looking for a project at the moment). ;)
--
Jeff Layton <[email protected]>
Sorry if I wasn't clear, but my suggestion was very hypothetical. File
capabilities are not supported today and won't be for the for forseeable
future. Adding support for them would be a (non-trivial) project and I'm
not aware of anyone working on it.
-- Jeff
On Thu, 2022-09-08 at 16:43 -0500, battery dude wrote:
> According to this configure file
> CONFIG_NFSD_V4_SECURITY_LABEL=y
> is enabled
>
> Jeff Layton <[email protected]> 于2022年9月8日周四 16:28写道：
> >
> > On Thu, 2022-09-08 at 21:17 +0000, Chuck Lever III wrote:
> > >
> > > > On Sep 8, 2022, at 5:03 PM, Jeff Layton <[email protected]> wrote:
> > > >
> > > > On Thu, 2022-09-08 at 20:24 +0000, Chuck Lever III wrote:
> > > > > [ This question comes up on occasion, so I've added a few interested
> > > > > parties to the Cc: list ]
> > > > >
> > > > > > On Sep 8, 2022, at 8:27 AM, battery dude <[email protected]> wrote:
> > > > > >
> > > > > > According to https://access.redhat.com/solutions/2117321 this article,
> > > > > > I want to ask, how to make NFS support the penetration of Linux
> > > > > > Capabilities
> > > > >
> > > > > That link is access-limited, so I was able to view only the top
> > > > > few paragraphs of it. Not very open, Red Hat.
> > > > >
> > > > > TL;DR: I looked into this while trying to figure out how to enable
> > > > > IMA on NFS files. It's difficult for many reasons.
> > > > >
> > > > >
> > > > > A few of these reasons include:
> > > > >
> > > > > The NFS protocol is a standard, and is implemented on a wide variety
> > > > > of OS platforms. Each OS implements its own flavor of capabilities.
> > > > > There's no way to translate amongst the variations to ensure
> > > > > interoperation. On Linux, capabilities(7) says:
> > > > >
> > > > > > No standards govern capabilities, but the Linux capability implementation is based on the withdrawn POSIX.1e draft standard; see ⟨https://archive.org/details/posix_1003.1e-990310⟩.
> > > > >
> > > > > I'm not sure how closely other implementations come to implementing
> > > > > POSIX.1e, but there are enough differences that interoperability
> > > > > could be a nightmare. Anything Linux has done differently than
> > > > > POSIX.1e would be encumbered by GPL, making it nearly impossible to
> > > > > standardize those differences. (Let alone the possible problems
> > > > > trying to cite a withdrawn POSIX standard in an Internet RFC!)
> > > > >
> > > > > The NFSv4 WG could invent our own capabilities scheme, just as was
> > > > > done with NFSv4 ACLs. I'm not sure everyone would agree that effort
> > > > > was 100% successful.
> > > > >
> > > > >
> > > > > Currently, an NFS server bases its access control choices on the
> > > > > RPC user that makes each request. We'd have to figure out a way to
> > > > > enable NFS clients and servers to communicate more than just user
> > > > > identity to enable access control via capabilities.
> > > > >
> > > > > When sending an NFS request, a client would have to provide a set
> > > > > of capabilities to the server so the server can make appropriate
> > > > > access control choices for that request.
> > > > >
> > > > > The server would have to report the updated capset when a client
> > > > > accesses and executes a file with capabilities, and the server
> > > > > would have to trust that its clients all respect those capsets
> > > > > correctly.
> > > > >
> > > > >
> > > > > Because capabilities are security-related, setting and retrieving
> > > > > capabilities should be done only over networks that ensure
> > > > > integrity of communication. So, protection via RPC-with-TLS or
> > > > > RPCSEC GSS with an integrity service ought to be a requirement
> > > > > both for setting and updating capabilities and for transmitting
> > > > > any protected file content. We have implementations, but there
> > > > > is always an option of not deploying this kind of protection
> > > > > when NFS is actually in use, making capabilities just a bit of
> > > > > security theater in those cases.
> > > > >
> > > > >
> > > > > Given these enormous challenges, who would be willing to pay for
> > > > > standardization and implementation? I'm not saying it can't or
> > > > > shouldn't be done, just that it would be a mighty heavy lift.
> > > > > But maybe other folks on the Cc: list have ideas that could
> > > > > make this easier than I believe it to be.
> > > > >
> > > > >
> > > >
> > > > I'm not disputing anything you wrote above, and I clearly haven't
> > > > thought through the security implications, but I wonder if we could
> > > > piggyback this info onto security label support somehow? That already
> > > > requires a (semi-opaque) per-inode attribute, which is mostly what's
> > > > required for file capabilities.
> > >
> > > That was the starting idea for accessing IMA metadata on NFS until
> > > we discovered that NFSv4 security labels are intended to enable only
> > > a single label per file. Capabilities are often present with SELinux
> > > labels.
> > >
> > > It would work for a proof of concept, though.
> > >
> >
> > Yeah, that why I was saying "piggyback".
> >
> > You'd need a combined SELinux+capabilities label (potentially with other
> > stuff in it as well). When you got one from the server, you'd have to
> > extract each piece and put in the right places in the inode.
> >
> > But, like I said...I haven't thought through the implications here at
> > all (and am not looking for a project at the moment). ;)
> > --
> > Jeff Layton <[email protected]>
--
Jeff Layton <[email protected]>
On Thu, Sep 08, 2022 at 08:24:02PM +0000, Chuck Lever III wrote:
> I'm not sure how closely other implementations come to implementing
> POSIX.1e, but there are enough differences that interoperability
> could be a nightmare. Anything Linux has done differently than
> POSIX.1e would be encumbered by GPL, making it nearly impossible to
> standardize those differences. (Let alone the possible problems
> trying to cite a withdrawn POSIX standard in an Internet RFC!)
I'm not a lawyer and I don't play one on TV; I haven't even stayed at
a Holiday Inn recently. :-)
However... please note that at least in the US, copyright does not
extend to *interfaces*. This is why we can replicate interfaces such
as openat(2), which first appeared in Solaris, not to mention things
like the read(2) system call and the options to fsck, which first
appared in Unix systems encumbered by the AT&T Copyright license.
(And some of these licenses even had AT&T's claim that Unix "methods
and concepts" were trade secrets, although MIT had always refused to
sign any such license agreements, since they didn't want to encumber
the brains of their undergraduates. So I've looked at BSD source code
as an MIT undergraduate without any kind of "Methods and Concepts"
taint, although trying to claim that the Unix methods and concepts are
a "trade secret" are kind of laughable at this point. :-)
> The NFSv4 WG could invent our own capabilities scheme, just as was
> done with NFSv4 ACLs. I'm not sure everyone would agree that effort
> was 100% successful.
Indeed, what the NFSv4 working group could do is to take a survey of
what capabilities are in use, and more importantly, how they are
defined, and create a superset of all of those capabilities and
publish it as an RFC. The tricky bit might be there were multiple
versions of the Posix.1e that were published, and different Legacy
Unices shipped implementations conforming to different drafts of
Posix.1e as part of the ill-fated "C2 by '92" initiative.
(The US government was trying to get all Unix systems to have the
minimal Orange Book certification so the US Military could use them in
classified systems, and they hadn't figured out that US procurements
for the computer industry had transitioned from being the body of the
dog to being the tail. For more details, see Steve Lipner's "The
Birth and Death of the Orange Book" published in the IEEE Annals of
the History of Computing, 2015.)
In any case, what this means is the exact details of what some
particular capability might control could differ from system to
system. OTOH, I'm not sure how much that matters, since capability
masks are applied to binaries, and it's unlikely that it would matter
that a particular capabiity on an executable meant for Solaris 2.4SE
with C2 certification might be confusing to AIX 4.3.2 (released in
1999; so much for C2 by '92) that supported Orange Book C2, since AIX
can't run Solaris binaries. :-)
> Given these enormous challenges, who would be willing to pay for
> standardization and implementation? I'm not saying it can't or
> shouldn't be done, just that it would be a mighty heavy lift.
> But maybe other folks on the Cc: list have ideas that could
> make this easier than I believe it to be.
... and this is why the C2 by '92 initiative was doomed to failure,
and why Posix.1e never completed the standardization process. :-)
Honestly, capabilities are super coarse-grained, and I'm not sure they
are all that useful if we were create blank slate requirements for a
modern high-security system. So I'm not convinced the costs are
sufficient to balance the benefits.
If I was going to start from scratch, and if I only cared about Linux
systems that supported ext4 and/or f2fs, I'd design something where
executables would use fsverity, and then combine it with an eBPF MAC
policy[1] that would key off of some policy identifier embedded in the
PKCS7 signature block located in the executable's fsverity metadata.
(The fsverity signature would be applied by a secure build service, to
guarantee exact correspondence between the binary and a specific
version checked into source control, to protect against the insider
threat of an engineer sneaking some kind of un-peer-reviewed back door
into the binary.) The policy identifier might be used to provide some
kind of MAC enforcement, perhaps using seccomp to enforce what system
calls and ioctls said executable would be allowed to execute, or some
other kind of MAC policy.
[1] https://lwn.net/Articles/809645/
Speaking totally hypothetically, of course. A bunch of what I've
described above isn't upstream, or even implemented yet. (Although if
someone's interest is piqued in implementing some of this, please
contact me off-line.)
- Ted
On Fri, Sep 09, 2022 at 05:23:46AM -0400, Theodore Ts'o wrote:
> On Thu, Sep 08, 2022 at 08:24:02PM +0000, Chuck Lever III wrote:
> > Given these enormous challenges, who would be willing to pay for
> > standardization and implementation? I'm not saying it can't or
> > shouldn't be done, just that it would be a mighty heavy lift.
> > But maybe other folks on the Cc: list have ideas that could
> > make this easier than I believe it to be.
>
> ... and this is why the C2 by '92 initiative was doomed to failure,
> and why Posix.1e never completed the standardization process. :-)
>
> Honestly, capabilities are super coarse-grained, and I'm not sure they
> are all that useful if we were create blank slate requirements for a
> modern high-security system. So I'm not convinced the costs are
> sufficient to balance the benefits.
I seem to recall the immediate practical problem people have hit is that
some rpms will fail if it can't set file capabilities. So in practice
NFS may not work any more for root filesystems. Maybe there's some
workaround.
Taking a quick look at my laptop, there's not as many as I expected:
[root@parkour bfields]# getcap -r /usr
/usr/bin/arping cap_net_raw=p
/usr/bin/clockdiff cap_net_raw=p
/usr/bin/dumpcap cap_net_admin,cap_net_raw=ep
/usr/bin/newgidmap cap_setgid=ep
/usr/bin/newuidmap cap_setuid=ep
/usr/sbin/mtr-packet cap_net_raw=ep
/usr/sbin/suexec cap_setgid,cap_setuid=ep
--b.
> On Sep 9, 2022, at 9:13 AM, J. Bruce Fields <[email protected]> wrote:
>
> On Fri, Sep 09, 2022 at 05:23:46AM -0400, Theodore Ts'o wrote:
>> On Thu, Sep 08, 2022 at 08:24:02PM +0000, Chuck Lever III wrote:
>>> Given these enormous challenges, who would be willing to pay for
>>> standardization and implementation? I'm not saying it can't or
>>> shouldn't be done, just that it would be a mighty heavy lift.
>>> But maybe other folks on the Cc: list have ideas that could
>>> make this easier than I believe it to be.
>>
>> ... and this is why the C2 by '92 initiative was doomed to failure,
>> and why Posix.1e never completed the standardization process. :-)
>>
>> Honestly, capabilities are super coarse-grained, and I'm not sure they
>> are all that useful if we were create blank slate requirements for a
>> modern high-security system. So I'm not convinced the costs are
>> sufficient to balance the benefits.
>
> I seem to recall the immediate practical problem people have hit is that
> some rpms will fail if it can't set file capabilities.
Indeed, that is the most common reason for a request to implement
capabilities for NFS files.
> So in practice NFS may not work any more for root filesystems.
"may not work any more" -- well let's be precise. NFS works for root,
but doesn't support distributions that require file capabilities on
certain executables. Thus it cannot be used in those cases.
> Maybe there's some workaround.
The workaround I'm familiar with is to use a local filesystem that
implements extended attributes, but store it on network-attached
block storage (eg iSCSI).
> Taking a quick look at my laptop, there's not as many as I expected:
>
> [root@parkour bfields]# getcap -r /usr
> /usr/bin/arping cap_net_raw=p
> /usr/bin/clockdiff cap_net_raw=p
> /usr/bin/dumpcap cap_net_admin,cap_net_raw=ep
> /usr/bin/newgidmap cap_setgid=ep
> /usr/bin/newuidmap cap_setuid=ep
> /usr/sbin/mtr-packet cap_net_raw=ep
> /usr/sbin/suexec cap_setgid,cap_setuid=ep
Yep, it's still a short list.
--
Chuck Lever
On 9/9/2022 2:23 AM, Theodore Ts'o wrote:
> On Thu, Sep 08, 2022 at 08:24:02PM +0000, Chuck Lever III wrote:
>> I'm not sure how closely other implementations come to implementing
>> POSIX.1e, but there are enough differences that interoperability
>> could be a nightmare. ...
> ...
>> The NFSv4 WG could invent our own capabilities scheme, just as was
>> done with NFSv4 ACLs. I'm not sure everyone would agree that effort
>> was 100% successful.
> Indeed, what the NFSv4 working group could do is to take a survey of
> what capabilities are in use, and more importantly, how they are
> defined, and create a superset of all of those capabilities and
> publish it as an RFC. The tricky bit might be there were multiple
> versions of the Posix.1e that were published, and different Legacy
> Unices shipped implementations conforming to different drafts of
> Posix.1e as part of the ill-fated "C2 by '92" initiative.
>
> ...
>
> In any case, what this means is the exact details of what some
> particular capability might control could differ from system to
> system. OTOH, I'm not sure how much that matters, since capability
> masks are applied to binaries, and it's unlikely that it would matter
> that a particular capabiity on an executable meant for Solaris 2.4SE
> with C2 certification might be confusing to AIX 4.3.2 (released in
> 1999; so much for C2 by '92) that supported Orange Book C2, since AIX
> can't run Solaris binaries. :-)
Data General's UNIX system supported in excess of 330 capabilities.
Linux is currently using 40. Linux has deviated substantially from
the Withdrawn Draft, especially in the handling of effective capabilities.
I believe that you could support POSIX capabilities or Linux capabilities,
but an attempt to support both is impractical. Supporting any given
UNIX implementation is possible, but once you get past the POSIX defined
capabilities into the vendor specific ones interoperability ain't gonna
happen.
>> Given these enormous challenges, who would be willing to pay for
>> standardization and implementation? I'm not saying it can't or
>> shouldn't be done, just that it would be a mighty heavy lift.
>> But maybe other folks on the Cc: list have ideas that could
>> make this easier than I believe it to be.
> .. and this is why the C2 by '92 initiative was doomed to failure,
> and why Posix.1e never completed the standardization process. :-)
The POSIX.1e effort wasn't completed because vendors lost interest
in the standards process and because they lost interest in the
evaluated security process. That, and we'd made way too many trips
to Poughkeepsie.
> Honestly, capabilities are super coarse-grained, and I'm not sure they
> are all that useful if we were create blank slate requirements for a
> modern high-security system. So I'm not convinced the costs are
> sufficient to balance the benefits.
Granularity was always a bone of contention in the working group.
What's sad is that granularity wasn't the driving force behind capabilities.
The important point was to separate privilege from UID 0. In the end
I think we'd have been better off with one capability, CAP_PRIVILEGED,
defined in the specification and a note saying that beyond that you were
on your own.
> If I was going to start from scratch, and if I only cared about Linux
> systems that supported ext4 and/or f2fs, I'd design something where
> executables would use fsverity, and then combine it with an eBPF MAC
> policy[1] that would key off of some policy identifier embedded in the
> PKCS7 signature block located in the executable's fsverity metadata.
> (The fsverity signature would be applied by a secure build service, to
> guarantee exact correspondence between the binary and a specific
> version checked into source control, to protect against the insider
> threat of an engineer sneaking some kind of un-peer-reviewed back door
> into the binary.) The policy identifier might be used to provide some
> kind of MAC enforcement, perhaps using seccomp to enforce what system
> calls and ioctls said executable would be allowed to execute, or some
> other kind of MAC policy.
>
> [1] https://lwn.net/Articles/809645/
>
> Speaking totally hypothetically, of course. A bunch of what I've
> described above isn't upstream, or even implemented yet. (Although if
> someone's interest is piqued in implementing some of this, please
> contact me off-line.)
>
> - Ted
https://discourse.pi-hole.net/t/ftl-not-running-in-web-interface/10412?page=2
https://serverfault.com/questions/886804/non-root-user-needing-chown-capability-on-nfs-client
other refer
Casey Schaufler <[email protected]> 于2022年9月9日周五 10:59写道：
>
> On 9/9/2022 2:23 AM, Theodore Ts'o wrote:
> > On Thu, Sep 08, 2022 at 08:24:02PM +0000, Chuck Lever III wrote:
> >> I'm not sure how closely other implementations come to implementing
> >> POSIX.1e, but there are enough differences that interoperability
> >> could be a nightmare. ...
> > ...
> >> The NFSv4 WG could invent our own capabilities scheme, just as was
> >> done with NFSv4 ACLs. I'm not sure everyone would agree that effort
> >> was 100% successful.
> > Indeed, what the NFSv4 working group could do is to take a survey of
> > what capabilities are in use, and more importantly, how they are
> > defined, and create a superset of all of those capabilities and
> > publish it as an RFC. The tricky bit might be there were multiple
> > versions of the Posix.1e that were published, and different Legacy
> > Unices shipped implementations conforming to different drafts of
> > Posix.1e as part of the ill-fated "C2 by '92" initiative.
> >
> > ...
> >
> > In any case, what this means is the exact details of what some
> > particular capability might control could differ from system to
> > system. OTOH, I'm not sure how much that matters, since capability
> > masks are applied to binaries, and it's unlikely that it would matter
> > that a particular capabiity on an executable meant for Solaris 2.4SE
> > with C2 certification might be confusing to AIX 4.3.2 (released in
> > 1999; so much for C2 by '92) that supported Orange Book C2, since AIX
> > can't run Solaris binaries. :-)
>
> Data General's UNIX system supported in excess of 330 capabilities.
> Linux is currently using 40. Linux has deviated substantially from
> the Withdrawn Draft, especially in the handling of effective capabilities.
> I believe that you could support POSIX capabilities or Linux capabilities,
> but an attempt to support both is impractical. Supporting any given
> UNIX implementation is possible, but once you get past the POSIX defined
> capabilities into the vendor specific ones interoperability ain't gonna
> happen.
>
> >> Given these enormous challenges, who would be willing to pay for
> >> standardization and implementation? I'm not saying it can't or
> >> shouldn't be done, just that it would be a mighty heavy lift.
> >> But maybe other folks on the Cc: list have ideas that could
> >> make this easier than I believe it to be.
> > .. and this is why the C2 by '92 initiative was doomed to failure,
> > and why Posix.1e never completed the standardization process. :-)
>
> The POSIX.1e effort wasn't completed because vendors lost interest
> in the standards process and because they lost interest in the
> evaluated security process. That, and we'd made way too many trips
> to Poughkeepsie.
>
> > Honestly, capabilities are super coarse-grained, and I'm not sure they
> > are all that useful if we were create blank slate requirements for a
> > modern high-security system. So I'm not convinced the costs are
> > sufficient to balance the benefits.
>
> Granularity was always a bone of contention in the working group.
> What's sad is that granularity wasn't the driving force behind capabilities.
> The important point was to separate privilege from UID 0. In the end
> I think we'd have been better off with one capability, CAP_PRIVILEGED,
> defined in the specification and a note saying that beyond that you were
> on your own.
>
> > If I was going to start from scratch, and if I only cared about Linux
> > systems that supported ext4 and/or f2fs, I'd design something where
> > executables would use fsverity, and then combine it with an eBPF MAC
> > policy[1] that would key off of some policy identifier embedded in the
> > PKCS7 signature block located in the executable's fsverity metadata.
> > (The fsverity signature would be applied by a secure build service, to
> > guarantee exact correspondence between the binary and a specific
> > version checked into source control, to protect against the insider
> > threat of an engineer sneaking some kind of un-peer-reviewed back door
> > into the binary.) The policy identifier might be used to provide some
> > kind of MAC enforcement, perhaps using seccomp to enforce what system
> > calls and ioctls said executable would be allowed to execute, or some
> > other kind of MAC policy.
> >
> > [1] https://lwn.net/Articles/809645/
> >
> > Speaking totally hypothetically, of course. A bunch of what I've
> > described above isn't upstream, or even implemented yet. (Although if
> > someone's interest is piqued in implementing some of this, please
> > contact me off-line.)
> >
> > - Ted
On Fri, Sep 09, 2022 at 08:59:41AM -0700, Casey Schaufler wrote:
>
> Data General's UNIX system supported in excess of 330 capabilities.
> Linux is currently using 40. Linux has deviated substantially from
> the Withdrawn Draft, especially in the handling of effective capabilities.
> I believe that you could support POSIX capabilities or Linux capabilities,
> but an attempt to support both is impractical.
Yeah, good point, I had forgotten about how we (Linux) ended up
diverging from POSIX 1.e when we changed how effective capabilities
were calculated.
> Supporting any given UNIX implementation is possible, but once you
> get past the POSIX defined capabilities into the vendor specific
> ones interoperability ain't gonna happen.
And from an NFS perspective, if we had (for example) a Trusted Solaris
trying to emulate Linux binaries over NFS with capabilities masks, I
suspect trying to map Linux's Capabilities onto Trusted Solaris's
implementation of POSIX 1.e would be the least of Oracle's technical
challenges. :-)
> > .. and this is why the C2 by '92 initiative was doomed to failure,
> > and why Posix.1e never completed the standardization process. :-)
>
> The POSIX.1e effort wasn't completed because vendors lost interest
> in the standards process and because they lost interest in the
> evaluated security process.
It was my sense was that the reason why they lost interested in the
evaluated security process was simply that the business case didn't
make any sense. That is, the $$$ they might get from US Government
sales was probability not worth the opportunity cost of the engineers
tasked to work on Trusted {AIX,DG,HPUX,Solaris}. Heck, I'm not sure
the revenue would balance out the _costs_, let alone the opportunity
costs...
> Granularity was always a bone of contention in the working group.
> What's sad is that granularity wasn't the driving force behind capabilities.
> The important point was to separate privilege from UID 0. In the end
> I think we'd have been better off with one capability, CAP_PRIVILEGED,
> defined in the specification and a note saying that beyond that you were
> on your own.
Well, hey, we almost have that already, sort of --- CAP_SYS_ADMIN ==
"root", for almost all intents and purposes. :-)
- Ted
On 9/11/2022 3:00 AM, Theodore Ts'o wrote:
> On Fri, Sep 09, 2022 at 08:59:41AM -0700, Casey Schaufler wrote:
>> Data General's UNIX system supported in excess of 330 capabilities.
>> Linux is currently using 40. Linux has deviated substantially from
>> the Withdrawn Draft, especially in the handling of effective capabilities.
>> I believe that you could support POSIX capabilities or Linux capabilities,
>> but an attempt to support both is impractical.
> Yeah, good point, I had forgotten about how we (Linux) ended up
> diverging from POSIX 1.e when we changed how effective capabilities
> were calculated.
>
>> Supporting any given UNIX implementation is possible, but once you
>> get past the POSIX defined capabilities into the vendor specific
>> ones interoperability ain't gonna happen.
> And from an NFS perspective, if we had (for example) a Trusted Solaris
> trying to emulate Linux binaries over NFS with capabilities masks, I
> suspect trying to map Linux's Capabilities onto Trusted Solaris's
> implementation of POSIX 1.e would be the least of Oracle's technical
> challenges. :-)
>
>>> .. and this is why the C2 by '92 initiative was doomed to failure,
>>> and why Posix.1e never completed the standardization process. :-)
>> The POSIX.1e effort wasn't completed because vendors lost interest
>> in the standards process and because they lost interest in the
>> evaluated security process.
> It was my sense was that the reason why they lost interested in the
> evaluated security process was simply that the business case didn't
> make any sense. That is, the $$$ they might get from US Government
> sales was probability not worth the opportunity cost of the engineers
> tasked to work on Trusted {AIX,DG,HPUX,Solaris}. Heck, I'm not sure
> the revenue would balance out the _costs_, let alone the opportunity
> costs...
A B1 evaluation cost the vendor $1M/year for 3 years. At the time we were
selling large systems for $10M-20M, so you didn't have to sell very many
to justify the expense. Alas, salesmanship beats technological leadership
more often than you'd hope.
>> Granularity was always a bone of contention in the working group.
>> What's sad is that granularity wasn't the driving force behind capabilities.
>> The important point was to separate privilege from UID 0. In the end
>> I think we'd have been better off with one capability, CAP_PRIVILEGED,
>> defined in the specification and a note saying that beyond that you were
>> on your own.
> Well, hey, we almost have that already, sort of --- CAP_SYS_ADMIN ==
> "root", for almost all intents and purposes. :-)
My, but did we have trouble teaching evaluators about CAP_SYS_ADMIN.
They had a very hard time understanding why we had to have a capability
for things that had nothing to do with the system security policy.
The problem is that including what CAP_SYS_ADMIN does in a "real"
security policy introduces an level of complexity that makes any kind
of analysis impractical. How does the ioctl() that reverses the spin
on a disk drive relate to DAC or MAC? What are the objects involved?
The big issue is that so few Linux kernel developers understand what
the Linux security policy is. So much emphasis has gone into "least
privilege" and "fine granularity" that it is rare to find someone who
is willing to think about the big picture.
> - Ted