Re: compile+link Fujitsu Linux

On Wed, 6 Feb 2008 20:13:38 -0800 (PST), Richard <riplin@xxxxxxxxxxxx> wrote:



Robert wrote:
On Wed, 6 Feb 2008 00:19:14 -0800 (PST), Richard <riplin@xxxxxxxxxxxx> wrote:

On Feb 6, 7:01 pm, Robert <n...@xxxxxx> wrote:

Well, no it doesn't do that. Not even close. But you still haven't
explained how your mechanism is 'better'. Given equal slackness in
permissions and such and users can access compilers then how is a
library any different ? Tools can push and pull stuff out of
libraries.

My security is better because it does not depend on file system permissions. It doesn't
depend on application code, either.

You claimed that your mechanism of having all the programs in one
library was better. That is was more reliable, more secure, easier to
deploy and faster.

It may be insignificantly faster in the CALL, but is slower on
startup. Deployment would only be 'easier' if you don't bother to
test. Reliability is worse because a 'missing file' stops the whole
application. Now you simply change the subject to something that is
completely independent of whether it uses libraries or individual
programs.

I talk about packaging called programs, you respond with security concerns. I respond to
those security concerns, you say it is irrelevant to packaging.

To me, security and packaging ARE unrelated. To you, they are related because you are
using file system permissions as program permissions. So long as you do that, you MUST use
dynamic loading. The security tail is wagging the program loading dog.

The goal of security is to prevent unauthorized people from seeing or changing certain
data. I do that by protecting the DATA; you do it by preventing them from running
programs.

As an analogy, suppose we are parents who want to prevent our kids from watching sex
movies on TV. You would do it by locking up the remote control, which is easily bypassed
with a universal remote. I would do it by telling the cable box to play the movies only
for designated users.

You claimed that your way was superior and the best that you have come
up with is 'less ugly'.

Simpler deployment, can be checked by auditing tools, faster loading, more reliable
because mid-run aborts due to missing program are impossible.

These are mere assertions. Having a script to do ZIP up everything is
just as simple as having a list for ld. Actually the ZIP list can be
*.so, so that is simpler and more reliable because it collects
everything and not just what is in the list of -ls. On unzipping it
won't remove a file that failed to be included in zip, while a library
short of one program will make that unavailable.

It is dangerous to use wildcards when building distribution packages such as zip or
library. You can inadvertantly include an untested version, an experimental test version,
even a trojan. A list guarantees that every component in the distribution package went
through the testing and review process.

The faulty lists I mentioned earlier are fixed in the first test cycle. After that, the
list does not change unless a newer version is linked to a defect report, code review and
test results.

'Simple' is 'what you are used to'. It may be simpler for you because
you already have it all set up. My way is simpler for me because I
have mine set up. You are attempting to claim some sort of 'global
universal truth' for your assertions (as usual).

I'm claiming that dynamic program structure is the norm and the default.

As I say, if you don't test what you are sending out then it _will_ be
less reliable.

We test every changed program when it is new. We don't retest it because another program
changed. That's a waste of time. If you find retesting necessary, you either have no
version control or hidden linkage between programs.

I use auditing tools, too. Programs COPY in a 'version.ws' that is
recreated each run of make so that I can check that a deployment to a
site has resulted in the correct versions of all programs, and this
_would_ pick up if anything is missing.

Good. Can you view the differences between ANY two versions, say between 2.2 and 2.4? How
do you propogate an emergency fix to 2.5, now in production, to ALL upstream versions --
say 3.1 in testing and 4.0 in development? That's the acid test for good version control.

Your claim about faster loading is also nonsense. Your startup will
take longer because you also load the library(s). I load on demand and
only load the one that are actually used. The startup time difference
may be noticable, the load of an individual program is not.

Load time is about the same per file, independent of size. Loading a big library is almost
as fast as the first dynamic load.

So, you would concede then that I have described a mechanism that
would not be able to be used by your system the way that you have it
and that this mechanism does protect the programs.

My system? I'd like to take credit for inventing Unix and ELF, but I believe Thompson and
Ritchie did it first.

I was not referring to your _Operating_System_ but to your system of
assembling programs.

It's the ELF system of assembling programs. Microsoft's PE system works the same way.

Security belongs in the called program, not the menu program. A user could write his own
program that calls yours.

Which is not an advantage for your library because he could call that
too.

So? The called program issues an Unauthorized message and exits.

And why do you think that "A user could write his own program that
calls yours." and have it work ?

I'd write a called program stub and put it ahead of yours in the library path. The stub
would display the contents of each parameter, then relay the call to the original. After
the boss runs it once, I'd write a menu program that passes the same values.

I don't have 30,000 developers trying to take me down. The level of
security is entirely appropriate for the types of business and clients
that I look after.

That's what everyone says. Do you expect them to say they have inadequate security? An
intrusion makes that announcement, after it's too late.
.

Relevant Pages

  • Re: compile+link Fujitsu Linux
    ... My security is better because it does not depend on file system permissions. ... Reliability is worse because a 'missing file' stops the whole ... completely independent of whether it uses libraries or individual ... take longer because you also load the library. ...
    (comp.lang.cobol)
  • Re: compile+link Fujitsu Linux
    ... My security is better because it does not depend on file system permissions. ... You would do it by locking up the remote control, ... libraries was 'more secure'. ...
    (comp.lang.cobol)
  • Re: How to find out access permissions for files?
    ... libraries. ... > permissions for (based on NTFS security). ... > will not click on files that he does not have access rights for, ...
    (microsoft.public.dotnet.security)
  • Re: compile+link Fujitsu Linux
    ... I wasn't trying to change your way of doing things, I was answering Charles' question. ... Charles was unfamiliar with Fujitsu on Unix. ... libraries was 'more secure'. ... YOU introduced application security, not I. ...
    (comp.lang.cobol)
  • Re: Refusing all permissions
    ... libraries which has extremely tight security (the libraries should refuse ... and see what permissions it is getting. ... Assembly declarative requests could be used for either one of the ...
    (microsoft.public.dotnet.security)