[cap-talk] Coding style in C++, isolating the bad parts with private constructors and friends?

[Ben Kloosterman]

Hi Rob ,

I don't see how we are improving things for security as any class can
inherit from FooCreator and do what it wants with Foo ( you can also
manually call the methods in a DLL even if private with some assembler) .
The only way would be too hide Foo in a different dll but C++ dlls are
public and global. The use of sealed and internal really helps C# here ( and
Java has similar constructs) .

>From a least privilege programming point of view it has some merit , since
it leads to less surface area exposed and hence harder to subvert when you
don't have code/admin access . 

Note least privilege coding often maps into standard patterns simply because
good OO coding states to expose the minimum needed. It is also good practice
to isolate system calls as you may be porting to a different platform.  I
haven't quite put my finger on this relationship but good OO code in most
cases creates  more secure code. 

Regards, 

Ben 

>-----Original Message-----
>From: cap-talk-bounces at mail.eros-os.org [mailto:cap-talk-
>bounces at mail.eros-os.org] On Behalf Of Rob Meijer
>Sent: Monday, December 14, 2009 8:48 PM
>To: General discussions concerning capability systems.
>Subject: [cap-talk] Coding style in C++, isolating the bad parts with
>private constructors and friends?
>
>In a chapter I am writing on practical least privilege in programming, I
>try to defend the use of friends and private constructors as a practical
>way to isolate the parts of the C++ code that actually communicate with
>external libraries and OS API's accessing shared-name-space designated
>resources.
>
>I know capability purist will probably say that as C++ isn't even memory
>safe, these coding styles don't really matter, but as I am trying to
>write
>my text based on the concept that even with flawed tools there is a lot
>of
>room to improve system integrity, I really do want to try my best at
>describing what measures are available while using memory unsafe
>languages.
>
>I would really like to hear if given that we know the limitations of
>languages like C++ within high integrity computing, if the below
>construct
>when used to isolate accessing shared-name-space designated resources are
>indeed a sufficiently high improvement to potential program integrity as
>to justify spending a section on explaining it:
>
>class FooCreator;
>class Foo {
>  public:
>    void dostuff(){
>       ..
>    }
>  private:
>    ..
>    Foo(){
>       ..
>    }
>    friend class FooCreator;
>};
>int main(int argc,char **argv);
>class FooCreator {
>  public:
>    Foo *createFoo(){
>       return new Foo();
>    }
>  private:
>    FooCreator() {
>    }
>    friend int main(int argc,char **argv);
>};
>
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk