You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Leif Hedstrom <zw...@apache.org> on 2011/07/16 19:11:40 UTC
Should we make Posix Capabilities "required" ?
On platforms that provides this feature, should we make it mandatory for
v3.2 ("trunk")? I think it'd simplify things, and avoid bug reports /
problems related to it. Granted, we still have to clean up our code mess
here (with duplicated code in 2-3 places), but keeping libcap optional
has little to gain I think (it's available pretty much on any reasonably
modern Linux, including old distros such as Fedora Core 7).
This would require libcap and libcap-devel (or libcap-dev) on Linux
platforms at least.
Thoughts?
-- Leif
Re: Should we make Posix Capabilities "required" ?
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jul 16, 2011, at 10:11 AM, Leif Hedstrom wrote:
> On platforms that provides this feature, should we make it mandatory for v3.2 ("trunk")? I think it'd simplify things, and avoid bug reports / problems related to it. Granted, we still have to clean up our code mess here (with duplicated code in 2-3 places), but keeping libcap optional has little to gain I think (it's available pretty much on any reasonably modern Linux, including old distros such as Fedora Core 7).
>
> This would require libcap and libcap-devel (or libcap-dev) on Linux platforms at least.
>
> Thoughts?
How would this affect support on Mac OS X?
Regards,
Alan
Re: Should we make Posix Capabilities "required" ?
Posted by "Alan M. Carroll" <am...@network-geographics.com>.
Saturday, July 16, 2011, 11:50:49 PM, you wrote:
> Unices do not support thread-based UIDs or privileges.
> (IIRC Windows does, but again, that is of no concern
> right now).
No. POSIX capabilities are thread local. That's why it doesn't play well with uid changing. Maybe it's not supposed to work this way but experimentally if you call cap_set_proc it changes the capabilities only in the current thread. That's why it must be done before the other threads are started. But if you change the effective user id, all capabilities in all threads are changed.
> We should foremost concentrate our efforts
> on centralizing privilege handling.
Yes.
For now, I have fixed the original libcap related problem but this will come up again at some point.
Re: Should we make Posix Capabilities "required" ?
Posted by Igor Galić <i....@brainsware.org>.
> [1] http://www.trustedbsd.org/privileges.html
As I already mentioned, the way to go for FreeBSD will
probably turn out to be capsicum. But that is of no
concern right now. (Only with 9.0)
Unices do not support thread-based UIDs or privileges.
(IIRC Windows does, but again, that is of no concern
right now). We should foremost concentrate our efforts
on centralizing privilege handling.
Whether we use for these efforts a library, such as
libcap or the raw syscalls - as we have to on Solaris
anyway - should be decided based on what turns out to
be most beneficial to the architecture.
One of the questions this opens is fitting the subject
of this thread: How do we handle system which do not
support POSIX capabilities?
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
Re: Should we make Posix Capabilities "required" ?
Posted by "Alan M. Carroll" <am...@network-geographics.com>.
According to what I found[1] this project is current inoperative and it's unclear when (if ever) it will be available on FreeBSD.
Personally, I think the better option is for me to fix the libcap related problems so it's not required. It's a bit ugly but not all that difficult. Now that I have more VMs with a bigger variety of OSes I can actually test my fixes.
For anyone wondering what the actual issue is, the root cause is that
1) TProxy needs capabilities in order to have the privilege of setting the transparency option at run time, but without having general root privileges. Other features are starting to use POSIXCaps but since it doesn't exist on all supported systems, we'll have to have an alternate and I don't see why that can't be used on Linux as well (except that it's probably less secure).
2) The threading model for POSIXCaps and setuid() are fundamentally incompatible, leading to the situation where POSIXCaps must be set *before* threads are started and the oldstyle setuid() needs to happen *after* threads are started. Dealing with this is straightforward, just ugly and effort intensive.
[1] http://www.trustedbsd.org/privileges.html
Saturday, July 16, 2011, 4:46:14 PM, you wrote:
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/secure-chroot.html#AEN1514
>> 3.5.2POSIX®.1e Process Capabilities
> On 7/16/11 5:19 PM, Igor Galić wrote:
>> Anyone know how to do this on FreeBSD?
Re: Should we make Posix Capabilities "required" ?
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/secure-chroot.html#AEN1514
>
> >
> > 3.5.2POSIX®.1e Process Capabilities
> >
> > POSIX® has released a working draft that adds event auditing,
> > access
> > control lists, fine grained privileges, information labeling, and
> > mandatory access control.
> >
> > This is a work in progress and is the focus of theTrustedBSD
> > <http://www.trustedbsd.org/>project. Some of the initial work has
> > been
> > committed to FreeBSD-CURRENT (cap_set_proc(3)).
http://www.freebsd.org/cgi/man.cgi?query=cap_set_proc&apropos=0&sektion=0&manpath=FreeBSD+9-current&format=html
Looks like the this documentation is from utopia :)
> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html
>
> > FreeBSD 5.X introduced new security extensions from the TrustedBSD
> > project based on thePOSIX®.1e draft. Two of the most significant
> > new
> > security mechanisms are file system Access Control Lists (ACLs) and
> > Mandatory Access Control (MAC) facilities.
http://www.freebsd.org/cgi/man.cgi?query=mac&sektion=3&apropos=0&manpath=FreeBSD+8.2-RELEASE
The MAC framework is comparable to SELinux (Not AppArmor)
and not quite what we're looking for, I suppose.
MAC, or any MLS (Multi-Level-Security) is generally controlled
by the Administrator, and the program executing within its
limits has no say. Which is the whole point, really.
Dropping privileges we go the other way around: We're granted
more privileges than we need, and drop to set of privileges
that our execution requires.
Googling, I just found something:
http://wiki.freebsd.org/201105DevSummit/Capsicum
It appears this will be supported in FreeBSD 9.0
aaand a whitepaper! (haven't read it yet)
http://www.usenix.org/events/sec10/tech/full_papers/Watson.pdf
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
GPG: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257
Re: Should we make Posix Capabilities "required" ?
Posted by Dossy Shiobara <do...@panoptic.com>.
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/secure-chroot.html#AEN1514
>
> 3.5.2POSIX®.1e Process Capabilities
>
> POSIX® has released a working draft that adds event auditing, access
> control lists, fine grained privileges, information labeling, and
> mandatory access control.
>
> This is a work in progress and is the focus of theTrustedBSD
> <http://www.trustedbsd.org/>project. Some of the initial work has been
> committed to FreeBSD-CURRENT (cap_set_proc(3)).
>
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/mac.html
> FreeBSD 5.X introduced new security extensions from the TrustedBSD
> project based on thePOSIX®.1e draft. Two of the most significant new
> security mechanisms are file system Access Control Lists (ACLs) and
> Mandatory Access Control (MAC) facilities.
On 7/16/11 5:19 PM, Igor Galić wrote:
> Anyone know how to do this on FreeBSD?
Re: Should we make Posix Capabilities "required" ?
Posted by Igor Galić <i....@brainsware.org>.
----- Original Message -----
> On platforms that provides this feature, should we make it mandatory
> for
> v3.2 ("trunk")? I think it'd simplify things, and avoid bug reports /
> problems related to it. Granted, we still have to clean up our code
That's two platforms right now: Solaris and Linux, and
right now our code doesn't use Solaris Privileges yet.
> mess
> here (with duplicated code in 2-3 places), but keeping libcap
> optional
> has little to gain I think (it's available pretty much on any
> reasonably
> modern Linux, including old distros such as Fedora Core 7).
>
> This would require libcap and libcap-devel (or libcap-dev) on Linux
> platforms at least.
It probably makes more sense to do that, rather than
use the raw syscalls. It still doesn't safe use from
"duplicating" code for each platform. Or, for both.
> Thoughts?
Anyone know how to do this on FreeBSD?
> -- Leif
i
--
Igor Galić
Tel: +43 (0) 664 886 22 883
Mail: i.galic@brainsware.org
URL: http://brainsware.org/
Fingerprint: 571B 8B8A FC97 266D BDA3 EF6F 43AD 80A4 5779 3257