limiting browse based on login?

[Fairlight]

At Wed, Sep 02, 2009 at 12:58:33PM -0400 or thereabouts, 
suspect Fairlight was observed uttering:
> All someone needs to do is:
> 
> [be somewhere they can drop to a shell]
> [drop to shell]
> PFQUAL=qualifier;export PFQUAL
> [run clerk or report]

You know, even that assumes some knowledge of fP.  But it's too complex.
You want to know how someone with no experience with fP would go about it?

1.  Gain access to shell.

2.  Check tty.

3.  Check process table and see what's running on your tty.

4.  Check system for that executable, assuming the path isn't in process
table.  This may be optional depending on the system and how it's called.

5.  On linux and solaris, check /proc and list the [pid]/fd/ directory to
find out what files are open.  On any system that has it, lsof is good as
well.  You don't even have to have your own process using it--once you've
checked the process table, just look for similar processes.

6.  'less /path/to/filename`

If you're willing to just look at the raw data (and the 20-byte headers
make records pretty distinct), that's all you need in most cases.  And
considering that probably 80%+ of the fP installs I've seen over the years
are run by people that chmod 777/666 whole trees, including filePro,
that'll work most of the time.  Actually, I'm betting it's 90%+, but I'm
trying to be conservative.  It's not like I keep count.  Let's just say I
can't remember the last system that I didn't have sole administrative
authority over that had tight permissions on fP files.

There are a bunch of ways you could find your way into it without intimate
knowledge of filePro.

And for the private comments I've gotten about "shell access is turned
off", there are a number of ways, depending what you have configured for
users.  There's the old !scc shortcut, but that's usually off now.  You may
or may not be able to suspend filePro's processes themselves, depending
on the version and environment.  People often stick other utilities in
runmenu based menus...Check Mail, etc.  The whole user experience is run
through runmenu in many places.  Or they have people edit files with a word
processor or editor directly invoked from filePro.  WordPerfect had a shell
out on some modifier of F4 that I can't remember directly but would find in
10 seconds.  Vim has :shell as a shell drop.  Mutt has ! to give you either
one command, or a whole shell if you just hit return.  The list doesn't
stop there, by any stretch.

This assumes you actually lock things down.  I know one company that sets
up systems for other companies, and I've heard -several- times from them
that, "Our users never see a shell."  Wrong.  Their method?  Present three
choices in a reconfiguration of the shell prompt and have an alias or
script there to catch the choice.  You're at a shell once you log in,
it just looks unconventional.  That won't even hold up against casual
scrutiny, yet they do it, assuming their users will never have an IQ above
40.  I mean, one typo, and the "typocommand: Command not found." will
give up the entire game.  God help them if they run into a black-hat type
with even a month of casual *nix knowledge--something made all the more
plausible sine linux became so popular.  Or a white-hat that gets curious
and then has fat fingers...

Why people assume a qualified file is secure is beyond me.  Most systems
I've seen over the years, you can waltz in and look at the data at will.
And a good percentage would quite possibly let you edit or delete it as
well.

If it's not five-nines airtight, don't present it as "secure".  Security
through obfuscation stopped being sufficient way over a decade ago.  It was
never really acceptable.

mark->
-- 
Audio panton, cogito singularis,