lkml.org 
[lkml]   [2009]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: drop SECURITY_FILE_CAPABILITIES?
Quoting Steve Grubb (sgrubb@redhat.com):
> On Tuesday 10 November 2009 10:53:49 am Serge E. Hallyn wrote:
> > > > Does anyone know of cases where CONFIG_SECURITY_FILE_CAPABILITIES=n
> > > > is still perceived as useful?
> > >
> > >
> > > As a library writer, I wished that the kernel behavior was either
> > > consistent, or there is an API that I can use to find out what model we
> > > are operating under. The biggest issue is that for a distribution we know
> > > the assumptions the distribution should be running under. But end users
> > > are free to build their own kernel that has it disabled. This has already
> > > lead to dbus not working at all.
> > >
> > > I also take issue with probing the capability version number returning
> > > EINVAL when its the only way to find out what the preferred version is.
> >
> > In 2007/2008, KaiGai had floated patches to export capability info
> > over securityfs. If it was something library writers and distros
> > wanted, we could resurrect those patches - and tack on some info
> > about cap-related kernel config.
>
> Unfortunately, I would have to support the kernels from 2.6.26->2.6.32 which
> presumably don't have this facility. So, I'm kind of stuck. I think in a
> previous discussion you mentioned that I could call getcap or
> prctl(PR_CAPBSET_READ) and check for CAP_SETPCAP. I think I have to go that
> direction for backwards compatibility.

Yes, I'm afraid so - unless /proc/config.gz happened to be available.
I suppose looking through /proc/1/status might be more reliable
actually, in case you were running in an already-partially-restricted
process tree.

> But back to detecting the capability version number...if I pass 0 as the
> version in the header, why can't the kernel just say oh you want the preferred
> version number, stuff it in the header, and return the syscall with success and
> not EINVAL?

This is something I believe Andrew has advocated in the past, but I
forget why. Andrew?

> Another irritation...if I want to clear the bounding set, I have to make a for
> loop and call prctl 34 times (once for each bit). I'd rather see a v4
> capability that takes the bounding set as part of the same syscall. Maybe all
> 3 of these could be fixed in the same OS release so that changing to v4 also
> signifies the other behavior changes.

I worry a bit about people confusing the bounding set as something
more flexible than it is, and/or getting lazy and using the bounding
set instead of fI|pI .vs. fP, but am not solidly against this.

Anyway, maybe we should get on thsi sooner rather than later...
Are there any other deficiencies people see in the current
API?

-serge


\
 
 \ /
  Last update: 2009-11-11 01:21    [W:0.060 / U:0.332 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site