POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?

POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 2101 bytes --]


Good day.


I'm not sure if it's the right list, but I believe the checks I'm
bumping against should be done in filesystem code.


I haven't used POSIX capabilities until now, and is trying to solve
classical backup case, when rsync process need to read whole fs, yet I
don't want to give it any extra privileges or root-level access to
everything.

CAP_DAC_READ_SEARCH seem to be well-suited and sufficient for the task,
according to docs:

  Bypass file read permission checks and directory read and execute
  permission checks.


I can see it bypassing directory checks, but it fails to bypass file
permission check.

For example, following code fails with "Capability: 1, Error: Permission
denied" on any file with 0000 permissions or, for example,
"/root/test1" file with 700 permissions, while succeeding for
"/root/test2" file with 755, with "/root" path having 700 mode and uid
of test-user is non-root.
Getcap of a binary gives "= cap_dac_read_search+eip", which is
consistent with capng_have_capability result.

  #include <stdio.h>
  #include <errno.h>
  
  #include <sys/types.h>
  #include <sys/stat.h>
  #include <fcntl.h>
  
  #include <cap-ng.h>
  
  int main(int argc, char **argv) {
  
  	printf( "Capability: %d, ",
  		capng_have_capability(CAPNG_EFFECTIVE, CAP_DAC_READ_SEARCH) );
  
  	int fd;
  	if ((fd = open(argv[1], O_RDONLY)) == -1) {
  		printf("Error: %s\n", (char*) strerror(errno));
  		return(1); }
  	else {
  		close(fd);
  		return(0); }
  
  };


I've tried this code with the same result for ext4, reiserfs and xfs.
CAP_DAC_OVERRIDE works for bypassing any permissions, but it's not
quite what I need.

Kernel is 2.6.32.2, with CONFIG_SECURITY_FILE_CAPABILITIES=y and
security labels enabled for all filesystems that support them.


So, now I'm puzzled: is that a normal behavior for this capability?
Am I doing something wrong?
Is there a bug in documentation, or prehaps I misinterpreted it?


Thanks in advance for shedding any light on this mystery.

-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?

[Serge E. Hallyn]

Quoting Mike Kazantsev (mk.fraggod@gmail.com):
> 
> Good day.
> 
> 
> I'm not sure if it's the right list, but I believe the checks I'm
> bumping against should be done in filesystem code.
> 
> 
> I haven't used POSIX capabilities until now, and is trying to solve
> classical backup case, when rsync process need to read whole fs, yet I
> don't want to give it any extra privileges or root-level access to
> everything.
> 
> CAP_DAC_READ_SEARCH seem to be well-suited and sufficient for the task,
> according to docs:
> 
>   Bypass file read permission checks and directory read and execute
>   permission checks.
> 
> 
> I can see it bypassing directory checks, but it fails to bypass file
> permission check.
> 
> For example, following code fails with "Capability: 1, Error: Permission
> denied" on any file with 0000 permissions or, for example,
> "/root/test1" file with 700 permissions, while succeeding for
> "/root/test2" file with 755, with "/root" path having 700 mode and uid
> of test-user is non-root.
> Getcap of a binary gives "= cap_dac_read_search+eip", which is
> consistent with capng_have_capability result.
> 
>   #include <stdio.h>
>   #include <errno.h>
>   
>   #include <sys/types.h>
>   #include <sys/stat.h>
>   #include <fcntl.h>
>   
>   #include <cap-ng.h>
>   
>   int main(int argc, char **argv) {
>   
>   	printf( "Capability: %d, ",
>   		capng_have_capability(CAPNG_EFFECTIVE, CAP_DAC_READ_SEARCH) );
>   
>   	int fd;
>   	if ((fd = open(argv[1], O_RDONLY)) == -1) {
>   		printf("Error: %s\n", (char*) strerror(errno));
>   		return(1); }
>   	else {
>   		close(fd);
>   		return(0); }
>   
>   };
> 
> 
> I've tried this code with the same result for ext4, reiserfs and xfs.
> CAP_DAC_OVERRIDE works for bypassing any permissions, but it's not
> quite what I need.

To be sure, are you saying that you've tested with CAP_DAC_OVERRIDE and
that works?  Are you running with selinux enforcing?

Note my own test on 2.6.33-rc2-00007-g85d1bb6 succeeds...

> Kernel is 2.6.32.2, with CONFIG_SECURITY_FILE_CAPABILITIES=y and
> security labels enabled for all filesystems that support them.
> 
> 
> So, now I'm puzzled: is that a normal behavior for this capability?
> Am I doing something wrong?
> Is there a bug in documentation, or prehaps I misinterpreted it?
> 
> 
> Thanks in advance for shedding any light on this mystery.
> 
> -- 
> Mike Kazantsev // fraggod.net

Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?

[Mike Kazantsev]

On Sun, 27 Dec 2009 16:06:10 -0600
"Serge E. Hallyn" <serue@us.ibm.com> wrote:

> Quoting Mike Kazantsev (mk.fraggod@gmail.com):
...
> > CAP_DAC_READ_SEARCH seem to be well-suited and sufficient for the
> > task, according to docs:
> > 
> >   Bypass file read permission checks and directory read and execute
> >   permission checks.
> > 
> > I can see it bypassing directory checks, but it fails to bypass file
> > permission check.
...
> 
> To be sure, are you saying that you've tested with CAP_DAC_OVERRIDE
> and that works?  Are you running with selinux enforcing?
> 
> Note my own test on 2.6.33-rc2-00007-g85d1bb6 succeeds...
> 


Basically, that's what I'm seeing:

  # uname -a
  Linux alpharius 2.6.32.2-fg.minion32 #1 SMP Mon Dec 28 09:52:53 YEKT
  2009 i686 Genuine Intel(R) CPU T2600 @ 2.16GHz GenuineIntel GNU/Linux
  
  # gcc test.c -lcap-ng -o /test
  # setcap 'cap_dac_read_search=ep' /test
  
  # getcap /test
  test = cap_dac_read_search+ep
  
  # touch /root/test{1,2}
  # chmod 600 /root/test1
  # chmod 644 /root/test2
  
  # ls -ld /root/{,test{1,2}}
  drwx------ 21 root root 4.0K Dec 28 09:21 /root/
  -rw-------  1  600 root    0 Dec 28 09:21 /root/test1
  -rw-r--r--  1  644 root    0 Dec 28 09:21 /root/test2
  
  # su -s /bin/zsh nobody
  
  % ls -ld /root/{,test{1,2}}
  ls: cannot access /root/test1: Permission denied
  ls: cannot access /root/test2: Permission denied
  drwx------ 21 root root 4.0K Dec 28 09:21 /root/
  
  % /sbin/getcap /test
  /test = cap_dac_read_search+ep
  
  % /test /root/test1
  Capability: 1, error: Permission denied
  
  % /test /root/test2
  Capability: 1,
  
  % exit
  
  # setcap 'cap_dac_override=ep' /test
  # su -s /bin/zsh nobody
  % /sbin/getcap /test
  /test = cap_dac_override+ep
  % /test /root/test1 
  Capability: 0,
  % /test /root/test2
  Capability: 0,


Guess your post means that it's not a normal behavior and should work
as documented in capabilities(7).

No SELinux here, just plain 2.6.32.2 kernel on a KVM machine, 2.6.32.1
yields the same result.
Filesystem is ext4, acl support is compiled in, but not enabled.


I'm checking out git kernel tree now to test with 2.6.33 and see if I
can get it working, and cherry-pick a patch from there, thanks for the
suggestion.


-- 
Mike Kazantsev // fraggod.net

Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?

[Mike Kazantsev]

On Mon, 28 Dec 2009 10:40:54 +0500
Mike Kazantsev <mk.fraggod@gmail.com> wrote:

> On Sun, 27 Dec 2009 16:06:10 -0600
> "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> 
> > Quoting Mike Kazantsev (mk.fraggod@gmail.com):
> ...
> > > CAP_DAC_READ_SEARCH seem to be well-suited and sufficient for the
> > > task, according to docs:
> > > 
> > >   Bypass file read permission checks and directory read and
> > > execute permission checks.
> > > 
> > > I can see it bypassing directory checks, but it fails to bypass
> > > file permission check.
> ...
> > 
> > To be sure, are you saying that you've tested with CAP_DAC_OVERRIDE
> > and that works?  Are you running with selinux enforcing?
> > 
> > Note my own test on 2.6.33-rc2-00007-g85d1bb6 succeeds...
> > 
> 

I've ran the test with 6b7b284958d47b77d06745b36bc7f36dab769d9b (tip of
Linus branch, tagged 2.6.33-rc2) and seeing the same results as quoted
below.
Then I checked out the tip of your branch (ea21e0baaa972aa0b4),
compiled with the same settings, rebooted VM, and it worked just as
it's supposed to.

Guess I'll try to find the relevant changes, but my experience with C
and kernel architecture is very limited, so if you can give any hint of
the possible cause, I'll be grateful.


To clarify the situation:

What I'm trying to do is to bypass file read permissions with
CAP_DAC_READ_SEARCH capability.

I've ran the same test with CAP_DAC_OVERRIDE just to see if FS DAC
bypassing capabilities are working at all, that one does.

Posix 1003.1e draft and capabilities(7) tells that CAP_DAC_READ_SEARCH
should bypass read permissions as well:
  This capability shall override file mode read and search access
  restrictions when accessing an object...

...but in practice, for some reason, in vanilla kernel, it doesn't, as
quoted below (test.c source can be seen in a thread-starter post).


> 
> Basically, that's what I'm seeing:
> 
>   # uname -a
>   Linux alpharius 2.6.32.2-fg.minion32 #1 SMP Mon Dec 28 09:52:53 YEKT
>   2009 i686 Genuine Intel(R) CPU T2600 @ 2.16GHz GenuineIntel
> GNU/Linux 
>   # gcc test.c -lcap-ng -o /test
>   # setcap 'cap_dac_read_search=ep' /test
>   
>   # getcap /test
>   test = cap_dac_read_search+ep
>   
>   # touch /root/test{1,2}
>   # chmod 600 /root/test1
>   # chmod 644 /root/test2
>   
>   # ls -ld /root/{,test{1,2}}
>   drwx------ 21 root root 4.0K Dec 28 09:21 /root/
>   -rw-------  1  600 root    0 Dec 28 09:21 /root/test1
>   -rw-r--r--  1  644 root    0 Dec 28 09:21 /root/test2
>   
>   # su -s /bin/zsh nobody
>   
>   % ls -ld /root/{,test{1,2}}
>   ls: cannot access /root/test1: Permission denied
>   ls: cannot access /root/test2: Permission denied
>   drwx------ 21 root root 4.0K Dec 28 09:21 /root/
>   
>   % /sbin/getcap /test
>   /test = cap_dac_read_search+ep
>   
>   % /test /root/test1
>   Capability: 1, error: Permission denied
>   
>   % /test /root/test2
>   Capability: 1,
>   
>   % exit
>   
>   # setcap 'cap_dac_override=ep' /test
>   # su -s /bin/zsh nobody
>   % /sbin/getcap /test
>   /test = cap_dac_override+ep
>   % /test /root/test1 
>   Capability: 0,
>   % /test /root/test2
>   Capability: 0,
> 


-- 
Mike Kazantsev // fraggod.net

Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?

[Serge E. Hallyn]

Quoting Mike Kazantsev (mk.fraggod@gmail.com):
> On Mon, 28 Dec 2009 10:40:54 +0500
> Mike Kazantsev <mk.fraggod@gmail.com> wrote:
> 
> > On Sun, 27 Dec 2009 16:06:10 -0600
> > "Serge E. Hallyn" <serue@us.ibm.com> wrote:
> > 
> > > Quoting Mike Kazantsev (mk.fraggod@gmail.com):
> > ...
> > > > CAP_DAC_READ_SEARCH seem to be well-suited and sufficient for the
> > > > task, according to docs:
> > > > 
> > > >   Bypass file read permission checks and directory read and
> > > > execute permission checks.
> > > > 
> > > > I can see it bypassing directory checks, but it fails to bypass
> > > > file permission check.
> > ...
> > > 
> > > To be sure, are you saying that you've tested with CAP_DAC_OVERRIDE
> > > and that works?  Are you running with selinux enforcing?
> > > 
> > > Note my own test on 2.6.33-rc2-00007-g85d1bb6 succeeds...
> > > 
> > 
> 
> I've ran the test with 6b7b284958d47b77d06745b36bc7f36dab769d9b (tip of
> Linus branch, tagged 2.6.33-rc2) and seeing the same results as quoted
> below.
> Then I checked out the tip of your branch (ea21e0baaa972aa0b4),

Oh, I don't update master on that tree, so that's actually a pretty
old and then heavily patched tree.  My test ran on Linus' latest
(6b7b284958d47b77d06745b36bc7f36dab769d9b) tree.

> compiled with the same settings, rebooted VM, and it worked just as
> it's supposed to.
> 
> Guess I'll try to find the relevant changes, but my experience with C

No no, that's a checkpoint/restart tree with a huge delta :)

> and kernel architecture is very limited, so if you can give any hint of
> the possible cause, I'll be grateful.
> 
> 
> To clarify the situation:
> 
> What I'm trying to do is to bypass file read permissions with
> CAP_DAC_READ_SEARCH capability.
> 
> I've ran the same test with CAP_DAC_OVERRIDE just to see if FS DAC
> bypassing capabilities are working at all, that one does.

Can you send me your .config?  Do you have any posix acl's set?

thanks,
-serge

Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?

[Mike Kazantsev]

[-- Attachment #1: Type: text/plain, Size: 2353 bytes --]

On Mon, 28 Dec 2009 10:22:05 -0600
"Serge E. Hallyn" <serue@us.ibm.com> wrote:

> > I've ran the test with 6b7b284958d47b77d06745b36bc7f36dab769d9b (tip of
> > Linus branch, tagged 2.6.33-rc2) and seeing the same results as quoted
> > below.
> > Then I checked out the tip of your branch (ea21e0baaa972aa0b4),
> 
> Oh, I don't update master on that tree, so that's actually a pretty
> old and then heavily patched tree.  My test ran on Linus' latest
> (6b7b284958d47b77d06745b36bc7f36dab769d9b) tree.

Indeed, I've tested it with v2.6.31 tag from Linus tree (which seem to
be closest to the tip of master branch of your tree) and
"/test /root/test1" works there as well.

Config: http://fraggod.net/share/config-v2.6.31


> > compiled with the same settings, rebooted VM, and it worked just as
> > it's supposed to.
> > 
> > Guess I'll try to find the relevant changes, but my experience with C
> 
> No no, that's a checkpoint/restart tree with a huge delta :)
>
> > and kernel architecture is very limited, so if you can give any hint of
> > the possible cause, I'll be grateful.
> > 
> > 
> > To clarify the situation:
> > 
> > What I'm trying to do is to bypass file read permissions with
> > CAP_DAC_READ_SEARCH capability.
> > 
> > I've ran the same test with CAP_DAC_OVERRIDE just to see if FS DAC
> > bypassing capabilities are working at all, that one does.
> 
> Can you send me your .config?  Do you have any posix acl's set?

Config: http://fraggod.net/share/config-v2.6.33-rc2

No, I don't have ACLs set for file/path and they aren't enabled on
mount, nor were they ever enabled for this filesystem at all.

Config has all devices set to virtio, so I guess it should run on any
other virtio-enabled i686 KVM virtual machine.


I've tried to disable every other FS (incl. ACL for ext4) and security
options - CONFIG_SECURITY, CONFIG_KEYS, CONFIG_SECURITY_NETWORK,
CONFIG_SECURITY_NETWORK_XFRM (CONFIG_SECURITY_FILE_CAPABILITIES=y seem
to be default for 2.6.33), but to no effect.

Tried same test for fresh-created ext4 (w/ v2.6.33-rc2), but it's the
same "permission denied".

Config: http://fraggod.net/share/config-v2.6.33-rc2-trimmed


I'll mail configs separately, since I believe the mailing list policy
is to disallow large messages.


-- 
Mike Kazantsev // fraggod.net

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?

[Serge E. Hallyn]

Quoting Serge E. Hallyn (serue@us.ibm.com):
> Quoting Mike Kazantsev (mk.fraggod@gmail.com):
> > CAP_DAC_READ_SEARCH seem to be well-suited and sufficient for the task,
> > according to docs:
> > 
> >   Bypass file read permission checks and directory read and execute
> >   permission checks.
> > 
> > 
> > I can see it bypassing directory checks, but it fails to bypass file
> > permission check.
> > 
> > For example, following code fails with "Capability: 1, Error: Permission
> > denied" on any file with 0000 permissions or, for example,
> > "/root/test1" file with 700 permissions, while succeeding for
> > "/root/test2" file with 755, with "/root" path having 700 mode and uid
> > of test-user is non-root.
> > Getcap of a binary gives "= cap_dac_read_search+eip", which is
> > consistent with capng_have_capability result.
> > 
> >   #include <stdio.h>
> >   #include <errno.h>
> >   
> >   #include <sys/types.h>
> >   #include <sys/stat.h>
> >   #include <fcntl.h>
> >   
> >   #include <cap-ng.h>
> >   
> >   int main(int argc, char **argv) {
> >   
> >   	printf( "Capability: %d, ",
> >   		capng_have_capability(CAPNG_EFFECTIVE, CAP_DAC_READ_SEARCH) );
> >   
> >   	int fd;
> >   	if ((fd = open(argv[1], O_RDONLY)) == -1) {
> >   		printf("Error: %s\n", (char*) strerror(errno));
> >   		return(1); }
> >   	else {
> >   		close(fd);
> >   		return(0); }
> >   
> >   };
> > 
> > 
> > I've tried this code with the same result for ext4, reiserfs and xfs.
> > CAP_DAC_OVERRIDE works for bypassing any permissions, but it's not
> > quite what I need.
> 
> To be sure, are you saying that you've tested with CAP_DAC_OVERRIDE and
> that works?  Are you running with selinux enforcing?
> 
> Note my own test on 2.6.33-rc2-00007-g85d1bb6 succeeds...

Egads, I'm sorry, Mike.  I was sure that if there was any problem it
would be in the exec_permission_lite path, that I had only checked DAC
perms on the path.  In fact, it's the DAC perms on the actual file
which are the problem.  I can reproduce your problem, and the following
patch fixes it.  Please confirm.

>From e923e0c84009c43748ad43d518ba9f702ad3dc1b Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <serue@us.ibm.com>
Date: Mon, 28 Dec 2009 21:11:46 -0800
Subject: [PATCH 1/1] generic_permission: MAY_OPEN is not write access

generic_permission was refusing CAP_DAC_READ_SEARCH-enabled
processes from opening DAC-protected files read-only, because
do_filp_open adds MAY_OPEN to the open mask.

Ignore MAY_OPEN.  After this patch, CAP_DAC_READ_SEARCH is
again sufficient to open(fname, O_RDONLY) on a file to which
DAC otherwise refuses us read permission.

Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
---
 fs/namei.c |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/fs/namei.c b/fs/namei.c
index 68921d9..b55440b 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -232,6 +232,7 @@ int generic_permission(struct inode *inode, int mask,
 	/*
 	 * Searching includes executable on directories, else just read.
 	 */
+	mask &= MAY_READ | MAY_WRITE | MAY_EXEC;
 	if (mask == MAY_READ || (S_ISDIR(inode->i_mode) && !(mask & MAY_WRITE)))
 		if (capable(CAP_DAC_READ_SEARCH))
 			return 0;
-- 
1.6.0.4

Re: POSIX CAP_DAC_READ_SEARCH doesn't bypass file read permissions?

[Mike Kazantsev]

On Mon, 28 Dec 2009 23:20:50 -0600
"Serge E. Hallyn" <serue@us.ibm.com> wrote:

> Quoting Serge E. Hallyn (serue@us.ibm.com):
> > Quoting Mike Kazantsev (mk.fraggod@gmail.com):
> > > CAP_DAC_READ_SEARCH seem to be well-suited and sufficient for the
> > > task, according to docs:
> > > 
> > >   Bypass file read permission checks and directory read and
> > > execute permission checks.
> > > 
> > > 
> > > I can see it bypassing directory checks, but it fails to bypass
> > > file permission check.
> 
> Egads, I'm sorry, Mike.  I was sure that if there was any problem it
> would be in the exec_permission_lite path, that I had only checked DAC
> perms on the path.  In fact, it's the DAC perms on the actual file
> which are the problem.  I can reproduce your problem, and the
> following patch fixes it.  Please confirm.
>

Indeed it works for both 2.6.32.2 and 2.6.33-rc2, thank you.


-- 
Mike Kazantsev // fraggod.net