Re: libcap-1.10-29.fscaps.28 is working, but libcap-2.02 gives an error on 2.6.24-rc5/6

2007-12-25 Thread Chris Friedhoff
works perfectly ... thanks

I updated my documentation accordingly
http://www.friedhoff.org/posixfilecaps.html

Cheers
Chris

On Mon, 24 Dec 2007 21:25:57 -0800
Andrew Morgan [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Please try:
 
 912c5acc280353540a3a6ece068c232d40f40534  libcap-2.03.tar.gz
 
 Cheers
 
 Andrew
 
 Chris Friedhoff wrote:
  Thank you for the answer.
  
  I was reading the mails on lsm, but it wasn't obvious to me, that right
  now libcap-2.0 is for 64-bit capabilities which are currently only in
  -mm.
  
  I personally find the situation right now a little bit unfortunate.
  During holidays - I can imagine - quite a few people like to try new
  features in anticipating the 2.6 24 release.
  Libcap-2.x is for 64-bit caps which is now only in 2.6.24-rc5-mm1
  and libcap-1.0 which works for 2.6.24-rc5/6 is not accessible.
  
  BTW your article got slashdotted:
  http://linux.slashdot.org/article.pl?sid=07/12/22/209212
  
  
  ... and have a nice christmas
  
  Chris
  
  
  
  On Sun, 23 Dec 2007 17:24:50 -0600
  [EMAIL PROTECTED] wrote:
  
  libcap-2.0 is for 64-bit capabilities which are currently
  only in -mm.  So switch your kernel to 2.6.24-rc5-mm1, or
  use the latest libcap-1.x.
 
  I actually confused myself the same way two weeks ago or
  so :)
 
  It almost seems worth it to have libcap-2.x use 32-bit file
  capabilities so long as no capabilities above 31 need to
  be set, just to avoid gratuitous headaches until 2.6.25.
  Andrew, what do you think?
 
  -serge
 
  Quoting Chris Friedhoff ([EMAIL PROTECTED]):
  Hello,
 
  I'm (still) updating my documentation on
  http://www.friedhoff.org/fscaps.html.
 
  I just learned, that KaiGai has taken his userspace tools offline and
  Andrews tools are updated and are now the prefered one.
 
  But I have a problem ...
 
  I tried it with 2.6.24-rc5 and 2.6.24-rc6 and with libcap 2.00, 2.01,
  20071203 (newest in git) on an 32 bit System
 
  setcap sets according to attr the capability attribute with 20 byte,
  whereby setfcaps sets a 12 byte value.
  getcap can read the value set by setfcaps but not by setcap.
  Executing a by setcap capability enabled binary gives an Invalid 
  argumet
  error.
  What am I missing?
 
  Thanks
  Chris
 
 
  Commands executed on a shell:
  -
 
  When I try to set a capability:
  ---
 
  $ sudo libcap-2.01/progs/setcap cap_net_raw=ep ping
  $ echo $?
  0
  I get:
  $ attr -l ping
  Attribute capability has a 20 byte value for ping
  $ libcap-2.01/progs/getcap ping
  Failed to get capabilities for file `ping' (Invalid argument)
  ./ping localhost
  bash: ./ping: Invalid argument
 
  But when I use KaiGai's tool:
  -
 
  $ sudo setfcaps -c cap_net_raw=p -e ping
  $ attr -l ping
  Attribute capability has a 12 byte value for ping
  $ libcap-2.01/progs/getcap ping
  $ ./ping localhost (works also)
 
 
  strace outputs:
  ---
 
  strace output without needed privileges
  ---
 
  $ ls -l libcap-2.01/progs/setcap
  -rwxr-xr-x 1 chris users 611672 Dec 23 14:02 libcap-2.01/progs/setcap
  $
  $ strace libcap-2.01/progs/setcap cap_net_raw=ep ping
  execve(libcap-2.01/progs/setcap, [libcap-2.01/progs/setcap, 
  cap_net_raw=ep, ping], [/* 55 vars */]) = 0
  uname({sys=Linux, node=apollo, ...}) = 0
  brk(0)  = 0x80ca000
  brk(0x80cacb0)  = 0x80cacb0
  set_thread_area({entry_number:-1 - 6, base_addr:0x80ca830, 
  limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, 
  limit_in_pages:1, seg_not_present:0, useable:1}) = 0
  brk(0x80ebcb0)  = 0x80ebcb0
  brk(0x80ec000)  = 0x80ec000
  capget(0x19980330, 0, NULL) = -1 EINVAL (Invalid argument)
  capget(0x19980330, 0, {0, 0, 0})= 0
  capset(0x19980330, 0, {0x8000 /* CAP_??? */, 0, 0}) = -1 EPERM 
  (Operation not permitted)
  dup(2)  = 3
  fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
  fstat64(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 1), ...}) = 0
  mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) 
  = 0xb7f14000
  _llseek(3, 0, 0xbff51724, SEEK_CUR) = -1 ESPIPE (Illegal seek)
  write(3, unable to set CAP_SETFCAP effect..., 72unable to set 
  CAP_SETFCAP effective capability: Operation not permitted
  ) = 72
  close(3)= 0
  munmap(0xb7f14000, 4096)= 0
  brk(0x80eb000)  = 0x80eb000
  exit_group(1)   = ?
  Process 3718 detached
 
 
  strace output with root owned suid bit binary
  -
  -rwsr-xr-x 1 root root 611672 Dec 23 14:02 libcap-2.01/progs/setcap*
  $
  $ strace libcap-2.01/progs/setcap cap_net_raw=ep ping
  execve(libcap-2.01/progs/setcap, 

Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning

2007-12-25 Thread Andrew Morton
On Thu, 20 Dec 2007 15:11:40 +1100 (EST) James Morris [EMAIL PROTECTED] wrote:

   +#ifdef CONFIG_SECURITY
   +extern unsigned long mmap_min_addr;
   +#endif
   +
#include asm/page.h
#include asm/pgtable.h
#include asm/processor.h
  
  Fine by me.
 
 I'll queue it for -mm  2.6.25.

I don't think we need the ifdef.  If someone incorrectly refers to this
then they'll get a link-time error rather than a compile-time error (bad). 
But we lose an ifdef (good).

-
To unsubscribe from this list: send the line unsubscribe 
linux-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [patch, rfc] mm.h, security.h, key.h and preventing namespace poisoning

2007-12-25 Thread James Morris
On Tue, 25 Dec 2007, Andrew Morton wrote:

 On Thu, 20 Dec 2007 15:11:40 +1100 (EST) James Morris [EMAIL PROTECTED] 
 wrote:
 
+#ifdef CONFIG_SECURITY
+extern unsigned long mmap_min_addr;
+#endif
+
 #include asm/page.h
 #include asm/pgtable.h
 #include asm/processor.h
   
   Fine by me.
  
  I'll queue it for -mm  2.6.25.
 
 I don't think we need the ifdef.  If someone incorrectly refers to this
 then they'll get a link-time error rather than a compile-time error (bad). 
 But we lose an ifdef (good).

Done,  rebased the git branch.


- James
-- 
James Morris
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe 
linux-security-module in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html