Thread: Hide source code

Hide source code

From
Márcio A. Sepp
Date:
 
Hi,
 
 
I'm looking for a way to hide the souce code of my system (functions).
 
In Oracle, I can wrap it.  Is there something that I can use to hide and/or wrap my source code?
 
 
Att.
 
Márcio A. Sepp
ZYON TECNOLOGIA LTDA

Re: Hide source code

From
Alvaro Herrera
Date:
On Sun, Jul 10, 2005 at 04:26:26AM -0300, Márcio A. Sepp wrote:

> I'm looking for a way to hide the souce code of my system (functions). 
> 
> In Oracle, I can wrap it.  Is there something that I can use to hide
> and/or wrap my source code? 

Write the functions in C and distribute only a binary?  Maybe in Java,
and use something like gcj; or Mono/.Net equivalents?  Write an Intercal
language handler?

-- 
Alvaro Herrera (<alvherre[a]alvh.no-ip.org>)
"You knock on that door or the sun will be shining on places inside you
that the sun doesn't usually shine" (en Death: "The High Cost of Living")


Re: Hide source code

From
Hans-Jürgen Schönig
Date:
Márcio A. Sepp wrote:
>  
> Hi,
>  
>  
> I'm looking for a way to hide the souce code of my system (functions).
>  
> In Oracle, I can wrap it.  Is there something that I can use to hide 
> and/or wrap my source code?
>  
>  
> Att.
>  
> Márcio A. Sepp
> ZYON TECNOLOGIA LTDA


Currently there is no way to do that.
Best regards,
    Hans


Re: Hide source code

From
David Fetter
Date:
On Sun, Jul 10, 2005 at 04:26:26AM -0300, M?rcio A. Sepp wrote:
> Hi,
> 
> I'm looking for a way to hide the souce code of my system
> (functions). 
> 
> In Oracle, I can wrap it.  Is there something that I can use to hide
> and/or wrap my source code? 

If you have code that you don't want people to take, use the copyright
and license system, which works, not the obfuscation system, which is
amazingly fragile.  And besides, what's so embarrassing about this
code that you don't want people to see it?

Cheers,
D
-- 
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!


Re: Hide source code

From
"Merlin Moncure"
Date:
> On Sun, Jul 10, 2005 at 04:26:26AM -0300, M?rcio A. Sepp wrote:
> > Hi,
> >
> > I'm looking for a way to hide the souce code of my system
> > (functions).
> >
> > In Oracle, I can wrap it.  Is there something that I can use to hide
> > and/or wrap my source code?
>
> If you have code that you don't want people to take, use the copyright
> and license system, which works, not the obfuscation system, which is
> amazingly fragile.  And besides, what's so embarrassing about this
> code that you don't want people to see it?

This was discusses extensively in the archives about a month ago.
Actually it is possible to 'hide' the source code so that a database
user can't view it (or anything else) in psql by manipulating system
schema permissions.

Regardless of your philosophical standpoint, many larger organizations
will feel uncomfortable with having unprivileged users having access to
all the database procedure source code.

Merlin


Re: Hide source code

From
David Fetter
Date:
On Mon, Jul 11, 2005 at 07:59:44AM -0400, Merlin Moncure wrote:
> > On Sun, Jul 10, 2005 at 04:26:26AM -0300, M?rcio A. Sepp wrote:
> > > Hi,
> > >
> > > I'm looking for a way to hide the souce code of my system
> > > (functions).
> > >
> > > In Oracle, I can wrap it.  Is there something that I can use to
> > > hide and/or wrap my source code?
> > 
> > If you have code that you don't want people to take, use the
> > copyright and license system, which works, not the obfuscation
> > system, which is amazingly fragile.  And besides, what's so
> > embarrassing about this code that you don't want people to see it?
> 
> This was discusses extensively in the archives about a month ago.
> Actually it is possible to 'hide' the source code so that a database
> user can't view it (or anything else) in psql by manipulating system
> schema permissions.

Interesting.  Again, this is pretty fragile with respect to, for
example, pg_dump(all).

> Regardless of your philosophical standpoint, many larger
> organizations will feel uncomfortable with having unprivileged users
> having access to all the database procedure source code.

That some "larger organizations" choose to use the known-unsafe method
of security by obscurity is not a reason for anybody here to expend
any effort helping them persist in this illusion: quite the opposite,
in fact.  "Larger organizations" are likely to have security needs
which they actually need to address, not to pretend they've addressed
while actually making things easy for attackers.

Cheers,
D
-- 
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!


Re: Hide source code

From
Josh Berkus
Date:
David,

> That some "larger organizations" choose to use the known-unsafe method
> of security by obscurity is not a reason for anybody here to expend
> any effort helping them persist in this illusion: quite the opposite,
> in fact.  "Larger organizations" are likely to have security needs
> which they actually need to address, not to pretend they've addressed
> while actually making things easy for attackers.

Hmmm, I agree with Merlin, I think.  It would be nice if users who didn't have 
permission to EXECUTE functions couldn't view their code, either. This would 
probably carry a performance penalty, though.

Users with EXECUTE permission not being able to see code just isn't practical; 
we support too many interpreted languages.  If this is a concern, use C 
functions and compile binaries.  That's secure.

-- 
Josh Berkus
Aglio Database Solutions
San Francisco


Re: Hide source code

From
David Fetter
Date:
On Mon, Jul 11, 2005 at 09:27:19AM -0700, Josh Berkus wrote:
> David,
> 
> > That some "larger organizations" choose to use the known-unsafe
> > method of security by obscurity is not a reason for anybody here
> > to expend any effort helping them persist in this illusion: quite
> > the opposite, in fact.  "Larger organizations" are likely to have
> > security needs which they actually need to address, not to pretend
> > they've addressed while actually making things easy for attackers.
> 
> Hmmm, I agree with Merlin, I think.  It would be nice if users who
> didn't have permission to EXECUTE functions couldn't view their
> code, either.

Why?

> This would probably carry a performance penalty, though.

> Users with EXECUTE permission not being able to see code just isn't
> practical; we support too many interpreted languages.  If this is a
> concern, use C functions and compile binaries.  That's secure.

With all due respect, it's not even *close* to secure.  There are
plenty of tools out there that allow a person to de-compile a shared
library.  A lot of people have learned the hard way over the decades
that any security measure that depends on the attacker's not knowing
the implementation details is fragile, often disastrously so, e.g. the
Enigma machine & friends.

There is no good reason for us to help perpetuate the myth of security
by obscurity, and plenty of good reasons for us *not* to do so.

Cheers,
D
-- 
David Fetter david@fetter.org http://fetter.org/
phone: +1 510 893 6100   mobile: +1 415 235 3778

Remember to vote!


Re: Hide source code

From
"Merlin Moncure"
Date:
> On Mon, Jul 11, 2005 at 07:59:44AM -0400, Merlin Moncure wrote:
> Interesting.  Again, this is pretty fragile with respect to, for
> example, pg_dump(all).

No, it isn't.  If you revoke permission on pg_proc, /df in psql will
fail, as will pg_dump.  Try it (you have to revoke all on pg_proc form
public).
See the log below:

C:\svn\rcsi\Etc>pg_dump -U test xxx
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  permission denied for
relation pg_proc
pg_dump: The command was: SELECT tableoid, oid, proname, prolang,
pronargs, proargtypes, prorettypproacl, pronamespace, (select usename from pg_user where proowner =
usesysid) as usename FROM pg_
oc WHERE NOT proisagg AND pronamespace != (select oid from pg_namespace
where nspname = 'pg_catalo
)

> > Regardless of your philosophical standpoint, many larger
> > organizations will feel uncomfortable with having unprivileged users
> > having access to all the database procedure source code.
>
> That some "larger organizations" choose to use the known-unsafe method
> of security by obscurity is not a reason for anybody here to expend
> any effort helping them persist in this illusion: quite the opposite,
> in fact.  "Larger organizations" are likely to have security needs
> which they actually need to address, not to pretend they've addressed
> while actually making things easy for attackers.

I think you are confusing 'security by obscurity' with 'security by
policy'.  The reasons for not allowing non-privileged users within your
company access to your source codes are highly nuanced.  Generally,
though, on the systems I admin information is doled out on a 'need to
know' basis.  The data in the database is managed in a highly controlled
fashion, why not the code?

Non technical users have no business looking at the code I write because
their bosses (not me) prefer it that way.  End of story.

observe:
C:\svn\rcsi\Etc>pg_dump -U test xxx
pg_dump: SQL command failed
pg_dump: Error message from server: ERROR:  permission denied for
relation pg_proc
pg_dump: The command was: SELECT tableoid, oid, proname, prolang,
pronargs, proargtypes, prorettypproacl, pronamespace, (select usename from pg_user where proowner =
usesysid) as usename FROM pg_
oc WHERE NOT proisagg AND pronamespace != (select oid from pg_namespace
where nspname = 'pg_catalo
)