[uml-devel] cap-bound not working in uml

[uml-devel] cap-bound not working in uml

[Frank v Waveren]

[-- Attachment #1.1: Type: text/plain, Size: 1787 bytes --]

I was trying to limit some unecessary capabilities in a UML instance
with /proc/sys/kernel/cap-bound, but it turned out not to take.

The source of the problem (or at least something a bit of the way up
the garden path of the problem) is at security/commoncap.c:140 at the
top of cap_bprm_apply_creds(bprm, unsafe):

   void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
   {
           /* Derived from fs/exec.c:compute_creds. */
           kernel_cap_t new_permitted, working;
   
           new_permitted = cap_intersect (bprm->cap_permitted, cap_bset);
           working = cap_intersect (bprm->cap_inheritable,
                                    current->cap_inheritable);
           new_permitted = cap_combine (new_permitted, working);
           ...

Here the new permitted set gets limited to the bits in cap_bset, which
is as it should be, but then the intersection of the of the current
and exec inheritable masks get added to that set, whereas as I
understand it, cap_bset should always be the bounding set.

I've tried commenting out that bit and everything worked as I'd hoped
(I haven't done extensive testing, but bounding the caps worked, as
did suids and such).

That doesn't explain why it works with those lines left in on a
non-UML kernel though, so I assume I'm missing something fundamental.

(My guest kernel is 
  Linux version 2.6.16.24 (fvw@jupiter.var.cx) (gcc version 4.0.3 20051201 
  (prerelease) (Debian 4.0.2-5)) #3 Sat Jul 15 16:54:20 CEST 2006
, should it matter)

-- 
Frank v Waveren                                  Key fingerprint: BDD7 D61E
fvw@var.cx                                              5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8              FA00 7D51 468D 62C8

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 375 bytes --]


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 194 bytes --]

_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] cap-bound not working in uml

[Blaisorblade]

On Saturday 15 July 2006 17:23, Frank v Waveren wrote:
> I was trying to limit some unecessary capabilities in a UML instance
> with /proc/sys/kernel/cap-bound, but it turned out not to take.

To remove capabilities from the whole system (i.e. all processes) the 
recommended way wasn't to use lcap (or a similar program bundled with 
libcap)?

> The source of the problem (or at least something a bit of the way up
> the garden path of the problem) is at security/commoncap.c:140 at the
> top of cap_bprm_apply_creds(bprm, unsafe):
>
>    void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
>    {
>            /* Derived from fs/exec.c:compute_creds. */
>            kernel_cap_t new_permitted, working;
>
>            new_permitted = cap_intersect (bprm->cap_permitted, cap_bset);
>            working = cap_intersect (bprm->cap_inheritable,
>                                     current->cap_inheritable);
>            new_permitted = cap_combine (new_permitted, working);
>            ...
>
> Here the new permitted set gets limited to the bits in cap_bset, which
> is as it should be, but then the intersection of the of the current
> and exec inheritable masks get added to that set, whereas as I
> understand it, cap_bset should always be the bounding set.
>
> I've tried commenting out that bit and everything worked as I'd hoped
> (I haven't done extensive testing, but bounding the caps worked, as
> did suids and such).
>
> That doesn't explain why it works with those lines left in on a
> non-UML kernel though, so I assume I'm missing something fundamental.
>
> (My guest kernel is
>   Linux version 2.6.16.24 (fvw@jupiter.var.cx) (gcc version 4.0.3 20051201
>   (prerelease) (Debian 4.0.2-5)) #3 Sat Jul 15 16:54:20 CEST 2006
> , should it matter)

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] cap-bound not working in uml

[Frank v Waveren]

[-- Attachment #1.1: Type: text/plain, Size: 2258 bytes --]

On Sun, Jul 16, 2006 at 12:31:51PM +0200, Blaisorblade wrote:
> On Saturday 15 July 2006 17:23, Frank v Waveren wrote:
> > I was trying to limit some unecessary capabilities in a UML instance
> > with /proc/sys/kernel/cap-bound, but it turned out not to take.
> 
> To remove capabilities from the whole system (i.e. all processes) the 
> recommended way wasn't to use lcap (or a similar program bundled with 
> libcap)?
Yup, lcap is just an interface to /proc/sys/kernel/cap-bound.


> > The source of the problem (or at least something a bit of the way up
> > the garden path of the problem) is at security/commoncap.c:140 at the
> > top of cap_bprm_apply_creds(bprm, unsafe):
> >
> >    void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
> >    {
> >            /* Derived from fs/exec.c:compute_creds. */
> >            kernel_cap_t new_permitted, working;
> >
> >            new_permitted = cap_intersect (bprm->cap_permitted, cap_bset);
> >            working = cap_intersect (bprm->cap_inheritable,
> >                                     current->cap_inheritable);
> >            new_permitted = cap_combine (new_permitted, working);
> >            ...
> >
> > Here the new permitted set gets limited to the bits in cap_bset, which
> > is as it should be, but then the intersection of the of the current
> > and exec inheritable masks get added to that set, whereas as I
> > understand it, cap_bset should always be the bounding set.
> >
> > I've tried commenting out that bit and everything worked as I'd hoped
> > (I haven't done extensive testing, but bounding the caps worked, as
> > did suids and such).
> >
> > That doesn't explain why it works with those lines left in on a
> > non-UML kernel though, so I assume I'm missing something fundamental.
> >
> > (My guest kernel is
> >   Linux version 2.6.16.24 (fvw@jupiter.var.cx) (gcc version 4.0.3 20051201
> >   (prerelease) (Debian 4.0.2-5)) #3 Sat Jul 15 16:54:20 CEST 2006
> > , should it matter)

-- 
Frank v Waveren                                  Key fingerprint: BDD7 D61E
fvw@var.cx                                              5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8              FA00 7D51 468D 62C8

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 375 bytes --]


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642

[-- Attachment #3: Type: text/plain, Size: 194 bytes --]

_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] cap-bound not working in uml

[Blaisorblade]

On Sunday 16 July 2006 14:05, Frank v Waveren wrote:
> On Sun, Jul 16, 2006 at 12:31:51PM +0200, Blaisorblade wrote:
> > On Saturday 15 July 2006 17:23, Frank v Waveren wrote:
> > > I was trying to limit some unecessary capabilities in a UML instance
> > > with /proc/sys/kernel/cap-bound, but it turned out not to take.
> >
> > To remove capabilities from the whole system (i.e. all processes) the
> > recommended way wasn't to use lcap (or a similar program bundled with
> > libcap)?
>
> Yup, lcap is just an interface to /proc/sys/kernel/cap-bound.

I remember maybe some differences UML specific capabilities code in arch/um 
(it used to clear some capabilities, i.e. /dev/mem or /dev/kmem access). 
Check for that...

> > > The source of the problem (or at least something a bit of the way up
> > > the garden path of the problem) is at security/commoncap.c:140 at the
> > > top of cap_bprm_apply_creds(bprm, unsafe):
> > >
> > >    void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
> > >    {
> > >            /* Derived from fs/exec.c:compute_creds. */
> > >            kernel_cap_t new_permitted, working;
> > >
> > >            new_permitted = cap_intersect (bprm->cap_permitted,
> > > cap_bset); working = cap_intersect (bprm->cap_inheritable,
> > >                                     current->cap_inheritable);
> > >            new_permitted = cap_combine (new_permitted, working);
> > >            ...
> > >
> > > Here the new permitted set gets limited to the bits in cap_bset, which
> > > is as it should be, but then the intersection of the of the current
> > > and exec inheritable masks get added to that set, whereas as I
> > > understand it, cap_bset should always be the bounding set.
> > >
> > > I've tried commenting out that bit and everything worked as I'd hoped
> > > (I haven't done extensive testing, but bounding the caps worked, as
> > > did suids and such).
> > >
> > > That doesn't explain why it works with those lines left in on a
> > > non-UML kernel though, so I assume I'm missing something fundamental.
> > >
> > > (My guest kernel is
> > >   Linux version 2.6.16.24 (fvw@jupiter.var.cx) (gcc version 4.0.3
> > > 20051201 (prerelease) (Debian 4.0.2-5)) #3 Sat Jul 15 16:54:20 CEST
> > > 2006 , should it matter)

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] cap-bound not working in uml

[Frank v Waveren]

[-- Attachment #1.1: Type: text/plain, Size: 1343 bytes --]

On Sun, Jul 16, 2006 at 09:24:36PM +0200, Blaisorblade wrote:
> On Sunday 16 July 2006 14:05, Frank v Waveren wrote:
> > On Sun, Jul 16, 2006 at 12:31:51PM +0200, Blaisorblade wrote:
> > > On Saturday 15 July 2006 17:23, Frank v Waveren wrote:
> > > > I was trying to limit some unecessary capabilities in a UML instance
> > > > with /proc/sys/kernel/cap-bound, but it turned out not to take.
> > >
> > > To remove capabilities from the whole system (i.e. all processes) the
> > > recommended way wasn't to use lcap (or a similar program bundled with
> > > libcap)?
> >
> > Yup, lcap is just an interface to /proc/sys/kernel/cap-bound.
> 
> I remember maybe some differences UML specific capabilities code in arch/um 
> (it used to clear some capabilities, i.e. /dev/mem or /dev/kmem access). 
> Check for that...

There used to be (in the tt mode jail support), but it's all gone now
(leaving some undefined prototypes in the headers about jail mode and
such by the way).

Oh well, I'll have to go poke in a live non-UML kernel and see what's
different, I'll keep the list posted.

-- 
Frank v Waveren                                  Key fingerprint: BDD7 D61E
fvw@var.cx                                              5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8              FA00 7D51 468D 62C8

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 348 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 194 bytes --]

_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] cap-bound not working in uml

[Frank v Waveren]

[-- Attachment #1.1: Type: text/plain, Size: 2545 bytes --]

The problem turned out to be caused in userspace, for some odd reason
the init on the gentoo disk image I'd nabbed did something that set
its inheritable mask to ~0. Not sure if its doing it on purpose, and I
still don't quite understand the code I quoted below, but it's not
relevant to UML, so I'll ask about it elsewhere. Sorry for the noise.

On Sun, Jul 16, 2006 at 02:05:31PM +0200, Frank v Waveren wrote:
> On Sun, Jul 16, 2006 at 12:31:51PM +0200, Blaisorblade wrote:
> > On Saturday 15 July 2006 17:23, Frank v Waveren wrote:
> > > I was trying to limit some unecessary capabilities in a UML instance
> > > with /proc/sys/kernel/cap-bound, but it turned out not to take.
> > 
> > To remove capabilities from the whole system (i.e. all processes) the 
> > recommended way wasn't to use lcap (or a similar program bundled with 
> > libcap)?
> Yup, lcap is just an interface to /proc/sys/kernel/cap-bound.
> 
> 
> > > The source of the problem (or at least something a bit of the way up
> > > the garden path of the problem) is at security/commoncap.c:140 at the
> > > top of cap_bprm_apply_creds(bprm, unsafe):
> > >
> > >    void cap_bprm_apply_creds (struct linux_binprm *bprm, int unsafe)
> > >    {
> > >            /* Derived from fs/exec.c:compute_creds. */
> > >            kernel_cap_t new_permitted, working;
> > >
> > >            new_permitted = cap_intersect (bprm->cap_permitted, cap_bset);
> > >            working = cap_intersect (bprm->cap_inheritable,
> > >                                     current->cap_inheritable);
> > >            new_permitted = cap_combine (new_permitted, working);
> > >            ...
> > >
> > > Here the new permitted set gets limited to the bits in cap_bset, which
> > > is as it should be, but then the intersection of the of the current
> > > and exec inheritable masks get added to that set, whereas as I
> > > understand it, cap_bset should always be the bounding set.
> > >
> > > I've tried commenting out that bit and everything worked as I'd hoped
> > > (I haven't done extensive testing, but bounding the caps worked, as
> > > did suids and such).
> > >
> > > That doesn't explain why it works with those lines left in on a
> > > non-UML kernel though, so I assume I'm missing something fundamental.

-- 
Frank v Waveren                                  Key fingerprint: BDD7 D61E
fvw@var.cx                                              5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8              FA00 7D51 468D 62C8

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 348 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 194 bytes --]

_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] cap-bound not working in uml

[Frank v Waveren]

[-- Attachment #1.1: Type: text/plain, Size: 375 bytes --]

Oh, and I should just add that UML is a great pleasure to debug
compared to kernel-mode-linux. Thanks for the wonderful work everyone!

-- 
Frank v Waveren                                  Key fingerprint: BDD7 D61E
fvw@var.cx                                              5D39 CF05 4BFC F57A
Public key: hkp://wwwkeys.pgp.net/468D62C8              FA00 7D51 468D 62C8

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 348 bytes --]

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV

[-- Attachment #3: Type: text/plain, Size: 194 bytes --]

_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel