When I asked the question below a while back, I got no response. Is there
really noone who can say anything about the future of capabilities?
Cheers
Michael
------- Forwarded message follows -------
Date sent: Fri, 10 May 2002 08:28:55 +0200 (MEST)
From: Michael Kerrisk <[email protected]>
Subject: Status of capabilities?
To: [email protected]
Gidday,
What are the current status and future of capabilites? There seems to be no
up-to-date information on this anywhere.
It seems capabilities have been partly implemented since 2.2. That is to
say:
1. The kernel checks (effective) capabilities when performing various
operations.
2. System calls are provided to raise and lower capabilties
What's still missing in 2.4, as far as I can see after reading the sources,
is the ability to set capabilities on executable files so that a process
gains those privileges when executing the file. I recall seeing some
information somewhere saying this wasn't possible / wasn't going to happen
for ext2. Is it on the drawing board for any file system?
Thanks
Michael
On Wed, 2002-06-26 at 06:40, Michael Kerrisk wrote:
> What's still missing in 2.4, as far as I can see after reading the sources,
> is the ability to set capabilities on executable files so that a process
> gains those privileges when executing the file. I recall seeing some
> information somewhere saying this wasn't possible / wasn't going to happen
> for ext2. Is it on the drawing board for any file system?
The 2.5 VFS supports Extended Attributes (since 2.5.3). I think the plan
was use EAs to store capabilities. So I believe that the infrastructure
is in place, someone with the proper skills just needs to:
1. Define how capabilities will be stored as a EA
2. Teach fs/exec.c to use the capabilities stored with the file
3. Write lscap(1)
4. Write chcap(1)
5. Audit/fix all SUID root binaries to use capabilities
6. Set appropriate capabilities with for each with chcap(1) and then:
# find / -type f -perm -4000 -user root -exec chmod u-s {} \;
7. Party and snicker in the general direction of that OS with the slogan
"One remote hole in the default install, in nearly 6 years!"
Dax Kelson
Guru Labs
Disclaimer: I could be completely wrong on any or all of the above
Dax Kelson <[email protected]>:
>
> On Wed, 2002-06-26 at 06:40, Michael Kerrisk wrote:
>
> > What's still missing in 2.4, as far as I can see after reading the sources,
> > is the ability to set capabilities on executable files so that a process
> > gains those privileges when executing the file. I recall seeing some
> > information somewhere saying this wasn't possible / wasn't going to happen
> > for ext2. Is it on the drawing board for any file system?
>
> The 2.5 VFS supports Extended Attributes (since 2.5.3). I think the plan
> was use EAs to store capabilities. So I believe that the infrastructure
> is in place, someone with the proper skills just needs to:
>
> 1. Define how capabilities will be stored as a EA
> 2. Teach fs/exec.c to use the capabilities stored with the file
> 3. Write lscap(1)
> 4. Write chcap(1)
> 5. Audit/fix all SUID root binaries to use capabilities
> 6. Set appropriate capabilities with for each with chcap(1) and then:
> # find / -type f -perm -4000 -user root -exec chmod u-s {} \;
> 7. Party and snicker in the general direction of that OS with the slogan
> "One remote hole in the default install, in nearly 6 years!"
Actually, I think most of that work has already been done by the Linux
Security Module project (well, except #7).
see:
http://lsm.immunix.org/
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
* Jesse Pollard ([email protected]) wrote:
>
> Actually, I think most of that work has already been done by the Linux
> Security Module project (well, except #7).
The LSM project supports capabilities exactly as it appears in the
kernel right now. The EA linkage is still missing. Of course, we are
accepting patches ;-)
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net
On Thu, 2002-06-27 at 14:54, Chris Wright wrote:
> * Jesse Pollard ([email protected]) wrote:
> >
> > Actually, I think most of that work has already been done by the Linux
> > Security Module project (well, except #7).
>
> The LSM project supports capabilities exactly as it appears in the
> kernel right now. The EA linkage is still missing. Of course, we are
> accepting patches ;-)
Has either lscap or chcap been written? I suppose not as that would
require a consensus on how capabilities would be stored as a EA.
That EA would need to be "special" and only be changeable by uid 0 (or
CAP_CHFSCAP).
So, has any of the below changed now that LSM has entered the picture?
1. Define how capabilities will be stored as a EA
2. Teach fs/exec.c to use the capabilities stored with the file
3. Write lscap(1)
4. Write chcap(1)
5. Audit/fix all SUID root binaries to be capabilities aware
6. Set appropriate capabilities with for each with chcap(1) and then:
# find / -type f -perm -4000 -user root -exec chmod u-s {} \;
7. Party and snicker in the general direction of that OS with the slogan
"One remote hole in the default install, in nearly 6 years!"
Dax Kelson
Chris Wright <[email protected]>:
> * Jesse Pollard ([email protected]) wrote:
> >
> > Actually, I think most of that work has already been done by the Linux
> > Security Module project (well, except #7).
>
> The LSM project supports capabilities exactly as it appears in the
> kernel right now. The EA linkage is still missing. Of course, we are
> accepting patches ;-)
Absolutely - I was just meaning that the effort of identifing the location(s)
in the kernel the hooks will have to be to set the capabilities from the EA
reference has been done. And in a central location too. Also, the hooks in the
filesystem will provide the location, if not access to, the EA when they
become available in/to the VFS (at least I hope that's where they end up).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]
Any opinions expressed are solely my own.
* Dax Kelson ([email protected]) wrote:
> On Thu, 2002-06-27 at 14:54, Chris Wright wrote:
> > * Jesse Pollard ([email protected]) wrote:
> > >
> > > Actually, I think most of that work has already been done by the Linux
> > > Security Module project (well, except #7).
> >
> > The LSM project supports capabilities exactly as it appears in the
> > kernel right now. The EA linkage is still missing. Of course, we are
> > accepting patches ;-)
>
> Has either lscap or chcap been written? I suppose not as that would
> require a consensus on how capabilities would be stored as a EA.
You might take a look at the linux-privs stuff. I believe it's pretty
out of date, but you can see where things left off. Specifically, the
fcap parts.
>
> That EA would need to be "special" and only be changeable by uid 0 (or
> CAP_CHFSCAP).
Actually, that would be CAP_SETFCAP as defined by the standard.
> So, has any of the below changed now that LSM has entered the picture?
No. The EA bits are the important part.
> 1. Define how capabilities will be stored as a EA
> 2. Teach fs/exec.c to use the capabilities stored with the file
> 3. Write lscap(1)
> 4. Write chcap(1)
> 5. Audit/fix all SUID root binaries to be capabilities aware
> 6. Set appropriate capabilities with for each with chcap(1) and then:
> # find / -type f -perm -4000 -user root -exec chmod u-s {} \;
> 7. Party and snicker in the general direction of that OS with the slogan
> "One remote hole in the default install, in nearly 6 years!"
thanks,
-chris
--
Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net