Re: drop SECURITY_FILE_CAPABILITIES?

[Serge E. Hallyn]

Quoting Steve Grubb (sgrubb@xxxxxxxxxx):
> On Tuesday 10 November 2009 09:07:39 am Serge E. Hallyn wrote:
> > I think that's the case most users will care about, whereas the
> > remaining differences between CONFIG_SECURITY_FILE_CAPABILITIES=y
> > and =n are that with CONFIG_SECURITY_FILE_CAPABILITIES=y :
> > 
> > 	(1) certain security hooks (task_setscheduler, task_setioprio, and
> > 	task_setnice) do capability set comparisions,
> > 	(2) it is possible to drop capabilities from the bounding set,
> > 	(3) it is possible to set per-task securelevels,
> > 	(4) and it is possible to add any capability to your inheritable
> > 	set if you have CAP_SETPCAP.
> > 
> > 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.

-serge
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/