Re: compile+link Fujitsu Linux

On Feb 6, 7:01 pm, Robert <n...@xxxxxx> wrote:
On Tue, 5 Feb 2008 11:29:58 -0800 (PST), Richard <rip...@xxxxxxxxxxxx> wrote:
On Feb 5, 6:52 pm, Robert <n...@xxxxxx> wrote:

In what way does _your_ mechanism do this ? If you libraryize your
programs and version them what is it that prevents another application
choosing the same name and having the same version and 'accidentally
installing that over yours' ?

One library file is less likely to be overwritten than one of several hundred.

Given that the likelyhood of any of mine being overwritten is zero,
then your assertion is meaningless. If there is (as you said there
was) a likelyhood of yours being overwritten then obviously your is
less reliable.


If it IS overwritten, the program will not start, because entry points will not match.

Exactly, your users will think that your system is unreliable.

You make claims about what may happen and seem to completely fail to
notice that the same problem could occur to your system. You claim a
completely spurious 'benefit' for your mechanism without knowing what
my mechanism actually is.

I know how dynamic Cobol calls work.

Version binding is normally done by the linker; it is normally not coded into the calling
program, thus you don't have to recompile the caller to change its binding, but you do
have to reload it. However, versioning can be controlled by the program by using the
dlvsym() function.

Why do you think that relevant ? I haven't recompiled 'the calling
program' for years.

If you're feeding it the program name via database, you could just as easily give it the
version string. That wouldn't require a recompilation either.

And I could even more easil;y just continue to use what has worked
well for me for decades without your unwanted complexifications.

We Have Always Done It That Way (WHADIT).

We do it that way because it works well.


Sounds like a golden opportunity for hackers.
mv login.so login.bkp
cp mylogin.so login.so
echo Ready for unauthenticated login.
....
mv login.bkp login.so

The users would _also_ need to have access to a compiler and to the
specifications of the framework, or the source code of that, to know
what 'mylogin' must do when a user logs in.

It's probably returning user and group in a structure. Write a stub to call it and look at
the structure returned.

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. Do you think that my program is called
'ThisisaSimpleMindedLogin.so' ?

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


You may as well claim that "anyone can write their own Unix login and
get root access".

No, but you'd be amazed at the percentage of systems where that's not necessary, because
they still have default logins.

Which is irrelevant to mine, whether it applies to yours I do not
know.

What makes you think that users have write access to the program
directory ? _I_ can drop in another program.

If they have read access, they can copy your whole directory structure to their home
directory, change permissions all they want, and run their local copy to find out the
boss' salary.

Well, actually, no they couldn't. I already told you that particular
programs can be set to be owned by the application administrator with
a group id of the trusted group and permissions of 640. It is only if
you are a member of the trusted group that give read access to run (or
copy) that program. Users can be members of several groups so access
can be very granular. Users not a member of that group will get a
'program not found' if they try to select it from the menu.

I assumed the files had world read permission. You stopped that approach.

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.

Thank you for starting to notice that some of us know what we are
doing.


If the library was required at start up (as in your mechanism) then
the application would fail to do anything for users not in _all_ the
trusted groups. Also you gather several programs into one library so
you have less, or no, usable granularity.

Granularity is in the called programs. It doesn't matter how they are packaged.

You did not follow that discussion then. If several programs are
packaged together in a library then the group permission restrictions
apply to all in the library.


My mechanism is oriented around data, not programs. If I want to protect month-end figures
in the accounting system, for example, I protect those numbers in the database.
Unauthorized users cannot change them by running the monthend program, by writing their
own program nor by running a database utility. Your notion of security by controlling
access to programs was obsolete twenty years ago.

Just change the subject then. You were trying to say that using
libraries was 'more secure'. You tried to say that 'home-grown' was
not secure.

Now you just change the subject to something different because you
failed to establish your unsupported and flawed assertions.

YOU introduced application security, not I.

No, that is wrong. I was saying that "the CALL dataname feature is
invaluable ..".

Then, out of the blue, you changed this to: "Now you're advocating
home-grown security."

You said "invaluable as it means that the menu program can use a data file to define what
is available in a particular application, or even to the particular user." That's
application security,

No. Wrong. You may have thought that security was the only reason for
this, but in my framework systems the 'user' identifies sets of data
files as well as applications because the systems are multi-company as
well as multi-user.

One company may have bespoke programs that suit a particular need and
the users in that company may have additional programs that are not
available to the same application run for another company.

and is irrelevant to dynamic loading. You could do the same if all
programs were in one library.

Well certainly your library could be used but would provide _no_
advantage and would not provide the advantages that I have already
given. For example if every program were in one library then that
would include the bespoke programs and a reissue of those would
require _EVERY_PROGRAM_ to be retested everytime to meet adequate
standards of reliability.

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

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

Actually, security belongs on the protected data, but that's
another topic.

Which is not an advantage for a library because it makes no
difference.

So you started by making claims for your library being better and we
find that, at best, it is merely equal and fails to meet the
requirements that I use.


In fact my system does implement field level security within the
system, but I don't run Banks or Stock Exchanges. The level of
security that I use is exactly correct for the businesses that use my
applications.

I worked with a system admin whose first job, after getting a degree in computer science,
was night manager at a Wal-Mart, where he ran the back-office computer. When the help desk
was talking him through a problem, they were giving him the root password on THEIR SERVER.
He knew exactly what that meant. He said, "What a gaping hole. I could have done
anything." He didn't; someone else might have.

The relevance of this little anecdote is ?

The moral is: don't assume users are too dumb to hack your system.

It seems that you allow them to break your by merely overwriting one
file.


If I DID want to limit access to a program function, the security check would be in the
function, not the file it is packaged in nor the calling program. Relying on Unix file
system to do application security is weak. For example, if the setgroupid bit of a program
file is set, it executes under the owner's group id rather than the user's.

Another straw-man. Why would I have setgroupid set ?

Because a user set it.

Excuse me, but how did a user get to set this ?

He would have to trick someone in the group to set it. Are priviliged users' .profiles
world writable? Is root's? How about shell logins?

And this is different from your library system in what way ?

Instead of addressing your claimed superiority you merely ramble on
about something else entirely unrelated, and straw-men, in the hope
that it may bamboozle. Perhaps that is your normal 'arguing' skills,
you win if they give up so it doesn't matter what the content is.

.

Relevant Pages

  • 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)
  • Re: compile+link Fujitsu Linux
    ... My security is better because it does not depend on file system permissions. ... completely independent of whether it uses libraries or individual ... take longer because you also load the library. ...
    (comp.lang.cobol)