On Thu, Feb 26, 2015 at 12:55 PM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > On Thu, Feb 26, 2015 at 12:51:57PM -0800, Andy Lutomirski wrote: >> On Thu, Feb 26, 2015 at 12:34 PM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: >> > On Thu, Feb 26, 2015 at 02:13:00PM -0600, Christoph Lameter wrote: >> >> On Thu, 26 Feb 2015, Serge E. Hallyn wrote: >> >> >> >> > Andrew Morgan was against that. What if we changed >> >> > >> >> > pE' = pP' & (fE | pA) >> >> > >> >> > to >> >> > >> >> > if (pA) >> >> > pE' = pP' & fE >> >> > else >> >> > pE' = pP' >> >> > >> >> >> >> Same problem as before. The ambient bits will not be set in pE'. >> > >> > And what if I weren't scatterbrained and we did >> > >> > if (pA) >> > pE' = pP' >> > else >> > pE' = pP' & fE >> > >> > All pP' bits would be set in pE'. >> >> That seems reasonable to me, except for my paranoia: >> >> What if there's a program with CAP_DAC_OVERRIDE in fP and fE set to >> the empty set (i.e. the magic effective bit cleared), and the program >> relies on that. A malicious user has CAP_NET_BIND and sets pA = >> CAP_NET_BIND. Boom! >> >> If we changed that to if (pA') and zeroed pA if fP is non-empty then >> this problem goes away. > > Hm, the problem is that then the empty pA is inherited by children. > I do see that any program with fP set should probably run with only > what it requested. Would > > if (pA && is_empty(fP)) > pE' = pP' > else > pE' = pP' & fE > > help? Or are you worried about a program with fP set which then > executes other programs? The particular worry I expressed there was just about pE. I'm still extremely nervous about allowing nonempty pA to propagate to setuid or nonzero fP programs. It's less obviously dangerous if pA is never a superset of pP, but it could still cause problems with setuid programs that execute intentionally deprivileged helpers. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
