-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thursday 13 July 2006 13:21, you wrote:
> Rion,
>
> Samba reportedly has some per-file-operation logging capabilities[1] which
> I am planning on investigating for a client very soon. If that applies,
> and you get to it before I do, it'd be great to hear what you find out.
I've only used SMB for connecting 'nix to M$ systems and as such am not a fan.
SYNOPSIS
Samba
DESCRIPTION
The Samba software suite is a collection of programs that implements
the Server Message Block (commonly abbreviated as SMB) protocol for
UNIX systems. This protocol is sometimes also referred to as the Common
Internet File System (CIFS), LanManager or NetBIOS protocol.
It's probably very capable but i have little experience using it and would be
curious
of comparisons to other FS's.
I wonder if the per-file analog holds for NFS, or some other sharing paradyme?
Altho the entire company net would include it's numerous websites and many
hosted clients, that/those system(s) would probably have a very different
topology than the corp. net (and it's sub-nets).
The corp net would represent it's various departments but be abstracted to
the point of accomodating anyone anytime anywhere (virtuality).
Of all it's servers, content managers are king, the crown jewels. These are
the data repositories and I would like them completely consolidated into
either Db or Fs servers.
I'm curious how the hardware abstraction is going to play out: distributing
the servers over a number of hosts, prob residing as xen, or openVZ, clients.
Not sure what my take is on a file server system, but I'd like to think out of
the box.
It could have an account for every user, grouped accordingly,using local
access strategies (jails?).
I suppose users could have (i know nfs has issues)
NFS perms issued on a per-user basis so they could remotely mount anything
from entire filesystems to individual directory trees. Maybe each user could
have their own personal filesystem, complete with a public_html directory.
I'm wondering if it would make sense to make the web server(s) document root(s)
remotely mounted fs's that would technically be w/in the file servers'
domain.
In addition to implementing LDAP, I'd like to find a solution that produces
something
akin to a password vault, e.g. a kind of central authorization/authentication
system
that manages individual users' passwords for the various systems they access.
>
> On the DB side: what DB is it, and how detailed are its transaction logs?
> Do all users access this DB with the same DB username? Do accesses come
> from fixed (or otherwise easily-traceable) IP addresses? Are the client DB
> connections to the server encrypted? (If so, packet analyzers will only
> help establish the existence of a connection to the server, and probably
> its time and duration, but not the content of its "conversation".)
Really good ?'s
My guess is mostly mysql for in-house use and general hosted web-clients.
But pgsql, sybase, oracle: their all w/in the relm of possibilities. How are
they
accessed? Good ? Frankly, I have no idea. Let's say either as web documents
or nativeOS (say, the TSP's) client gui's. I could arrange for each
host/server
to have different user ID's, but that wouldn't improve per-user logging. And
filtering sql logs on "select" statements to tracking mysqldumps would be
practically
impossible (i think).
>
> HbIDS like Tripwire are great for knowing if a file changed, but I don't
> know whether they are generally "triggerable" by file access alone. Most
> seem geared towards squawking if a file changes. Can anyone else shed some
> light on this aspect?
You are right. What I'm basically looking for would be like a .bash_history
file that can be used to update an 'activities' database. 'Course that wouldn't
cover the 'pointy-clicky' stuff, or the actions of any given application.
What I really, REALLY, dont want is going down the road of keyloggers and such,
That's bites big time.
>
> The big problem: this whole affair is complicated by the fact that, in most
> cases, the very act of viewing data from a server via a given machine
> requires that the data be copied from the server to the local box (even if
> the user doesn't explicitly drag-and-drop the file from the server to their
> local disk)*.
It's one thing to harden data from unauth access. But users who pass auth access
and are entitled to the data basically move it (clearly/crypted) to their own
environment/screen.
How can a trigger be set up to notify 'higher' when that user has just plain
'taken too
much, too fast' (like 20million ss#'s or cc#'s)
> From the perspective of using your captured/logged info as
> evidence: is it easy to discriminate between joedokes' legitimate access
> and illegitimate access, if he has been granted use of these data for the
> purposes of doing his job?
Of course, much energy has been put into un-warranted access; tracking/logging
denied access to anything by anybody; from hacking attempts to failed logins.
Ideally, any user only 'sees' what they are perm'd to see, making it easier to
detect if they happen to be where they don't belong.
>
> * Lessig: "Enter the Internet. Every act is a copy, which means all of
> these unregulated uses disappear."[2]
>
> This would seem similar to the problems encountered by people building DRM
> (digital rights management) systems for audio/video media files or e-books.
> The best these folks can seem to come up with is to lock the users into the
> controlled environment of a known, standardized player/viewer app, and hope
> that the user's kung fu isn't good enough to make an end-run around the
> protections in place.
That's a pretty good comparison, thought i cant imagine implementing that
'trusted' computing application/system which gives Sony wet dreams.
Even when MS/Intel build it, the hackers will break it. Since I just want to
know, not necess. prevent, data transfer, there's got to be an easier way.
>
> As far as I can tell, unless you can guarantee the environment in which the
> user interacts with the data to prevent them from taking the data with them
> (i.e. control the box), there are not a ton of options. If you CAN control
> the workstation and the viewing software they use to access the data (and,
> more importantly, THEY can't), you can probably leverage SOME logging to
> your advantage. Even then, I imagine you'd need VERY verbose filesystem
> logging on the workstation end to get what you seem to be looking for.
I envision each dept. utilizing thin-clients (i suppose they could be diskless,
i suppose a kernel could be built that wont write to fs's if they are on a
dev other than a harddrive?), but these measures defeat the purpose of
user-virtualization and tele-work from anywhere.
Maybe i could implement 2 diff strategies, one for in-house (having more
built-in oversight) and another for remote (necessitating more logging
and monitoring).
>
> Schneier and/or Bauer might say that this is one of those places where
> (current) technology leaves off, and policy (read: NDA and insurance (as
> in, "loss/liability coverage") must pick up the slack. If you're like me,
> though, that's scant comfort when sensitive data go walking out the door.
Tell me about it. Forget hackers, SATAN worshipers, packet sniffers, and the
like. The biggest hits come from those you trust.
Rion
- --
3010 Rte 109
Waterville, VT 05492
email: rion_at_dluz.com
web: http://dluz.com/Rion/
Phone: 802.644.2255
L I N U X .~.
Choice /V\
of a GNU /( )\
Generation ^^-^^
POSIX
RULES
George Bush of the Borg: Resistance is fertile, you will be assemblated
Gods don't kill people, people with gods kill people.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFEtwdM94WPEVwn1ncRAvFdAKCNOae604bucqpTOTKU0KUk/Q2nsACghZrE
40Rk2hZSg4wzmRysX3kCDg0=
=6goG
-----END PGP SIGNATURE-----
