<ph conref="../conrefs.dita#prod/productshortname"></ph> defenses against +threats

Return-Path: X-Original-To: apmail-db-derby-commits-archive@www.apache.org Delivered-To: apmail-db-derby-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5E591117B0 for ; Mon, 19 May 2014 20:10:45 +0000 (UTC) Received: (qmail 69460 invoked by uid 500); 19 May 2014 20:10:45 -0000 Delivered-To: apmail-db-derby-commits-archive@db.apache.org Received: (qmail 69437 invoked by uid 500); 19 May 2014 20:10:45 -0000 Mailing-List: contact derby-commits-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Derby Development" List-Id: Delivered-To: mailing list derby-commits@db.apache.org Received: (qmail 69430 invoked by uid 99); 19 May 2014 20:10:45 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 May 2014 20:10:45 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 19 May 2014 20:10:27 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 0442C2388BCD; Mon, 19 May 2014 20:09:41 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1596037 [7/13] - in /db/derby/docs/trunk: ./ src/security/ Date: Mon, 19 May 2014 20:09:36 -0000 To: derby-commits@db.apache.org From: chaase3@apache.org X-Mailer: svnmailer-1.0.9 Message-Id: <20140519200941.0442C2388BCD@eris.apache.org> X-Virus-Checked: Checked by ClamAV on apache.org Added: db/derby/docs/trunk/src/security/csecintroderbydefenses.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecintroderbydefenses.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecintroderbydefenses.dita (added) +++ db/derby/docs/trunk/src/security/csecintroderbydefenses.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,88 @@ + + + + + +<ph conref="../conrefs.dita#prod/productshortname"></ph> defenses against +threats + provides +numerous defenses against security threats. + + +

These defenses are described in the following table.

+ +<ph conref="../conrefs.dita#prod/productshortname"></ph> defenses +This table lists and describes defenses against threats, including who is responsible for implementing each defense. + + + +Defense +Task Owner +Description + + + + +Java security +System Administrator +Using a Java SecurityManager and policy +file, the System Administrator can restrict the permissions granted to +user-written code. The System Administrator can also restrict the permissions +granted to +itself. + + +SSL/TLS +System Administrator +The System Administrator can require that SSL/TLS be used to +encrypt network traffic between + clients and servers, +along the way raising an extra authentication hurdle. + + +Encryption +Database Owner +A Database Owner can require that the data for an application +be encrypted before being stored on disk. This makes it expensive to steal and +corrupt the data. + + +Authentication +Database Owner +Using usernames and passwords, a Database Owner can restrict +access to an application's data. + + +Coarse-grained authorization +Database Owner +A Database Owner can divide an application's users into three +groups: those with no privileges, those with read-only privileges, and those +with read-write privileges. + + +Fine-grained SQL authorization +Database Owner +By using SQL GRANT and REVOKE statements, a Database Owner +can further restrict access to fine-grained pieces of data and code. + + + +

+ + Propchange: db/derby/docs/trunk/src/security/csecintroderbydefenses.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecintromapping.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecintromapping.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecintromapping.dita (added) +++ db/derby/docs/trunk/src/security/csecintromapping.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,126 @@ + + + + + +Defenses mapped to threats +The following table maps defenses to examples of threats that they +parry. + + +

This matrix can help you decide whether you need to configure specific +defenses. Consult this table if you decide NOT to configure a defense -- make +sure that you are still shielded from the corresponding threats.

+ +<ph conref="../conrefs.dita#prod/productshortname"></ph> defenses +For each defense, this table provides the threatened damages, attackers, attack techniques, and vulnerabilities. + + + +Defense +Damages +Attackers +Techniques +Vulnerabilities + + + + +Java security +Theft, corruption, denial of service +Insiders and outsiders +Malware, physical access +Network JDBC, unbounded growth, CPU hogging, launch +privileges, user code, open source + + +SSL/TLS +Theft and corruption +Insiders and outsiders +Man-in-the middle, eavesdropping, physical access +Network JDBC, cleartext traffic + + +Encryption +Theft and corruption +Chiefly insiders +Physical access +Open source + + +Authentication +Theft, corruption, denial of service +Insiders and outsiders +Probing +Superusers + + +Coarse-grained authorization +Theft, corruption, denial of service +Insiders and outsiders +Probing +Superusers + + +Fine-grained SQL authorization +Theft, corruption, denial of service +Insiders and outsiders +Probing +Superusers + + +Firewalls +Theft, corruption, denial of service +Insiders and outsiders +Probing +Network JDBC + + +Accounts +Theft, corruption, denial of service +Insiders +Man-in-the-middle, malware, physical access +Launch privileges, user code + + +Physical locks +Theft, corruption, denial of service +Insiders +Man-in-the-middle, malware, physical access +Launch privileges, user code + + +Secure traffic +Theft and corruption +Insiders +Man-in-the-middle, eavesdropping +Cleartext traffic + + +File permissions +Theft, corruption, denial of service +Insiders and outsiders +Malware +Launch privileges, user code, open source + + + +

+ + Propchange: db/derby/docs/trunk/src/security/csecintromapping.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecintrootherdefenses.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecintrootherdefenses.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecintrootherdefenses.dita (added) +++ db/derby/docs/trunk/src/security/csecintrootherdefenses.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,49 @@ + + + + + +Defenses outside of +<ph conref="../conrefs.dita#prod/productshortname"></ph> +In addition to the defenses provided by +, you should take +advantage of defenses provided by your machine and intranet. + + +

It is important to configure these defenses to protect + from attacks by both +outsiders and insiders.

Firewalls: Limit network access to the machine that runs +.
Accounts: Limit login access to the machine that runs +. Centrally administer +accounts using, for instance, an LDAP server.
Physical locks: Limit physical access to the machine that runs +.
Secure traffic: Encrypt the traffic that flows on your internal +network.
File permissions: Restrict the file permissions granted to the +account that launches +.
Quotas: Limit the file space and CPU that an account can +consume.

+ + Propchange: db/derby/docs/trunk/src/security/csecintrootherdefenses.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecintrosafer.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecintrosafer.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecintrosafer.dita (added) +++ db/derby/docs/trunk/src/security/csecintrosafer.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,58 @@ + + + + + +Designing safer <ph conref="../conrefs.dita#prod/productshortname"></ph> +applications +The following tips should help you write and deploy safer +applications that use . + + + +

Create a launch account: Create an operating system account for the +System Administrator. This will be the account that launches +. This account should +not be the operating system's superuser.
Limit file permissions: Limit the file permissions of this System +Administrator account to just the directories that the application should be +allowed to read and write. Do not grant read or write access on these +directories to any other operating system accounts.
Create a policy file: Write your own Java Security policy that +restricts the directories that + can access and the +sockets on which it can accept connections. See + for more information.
Prevent JDBC leaks: Do not let JDBC connections leak outside your +intranet's firewall. If possible, design your application so that external +clients talk to an application server, which in turn communicates with +. Limit the JDBC +connections to communication between the application server and +.
Protect against injection: Do not construct queries by concatenating +strings that are filled in by clients. To parameterize your queries, use JDBC +? parameters in PreparedStatements.
Deploy your shields: By default, enable all defenses mentioned in +this section. If you need to turn off a defense for performance reasons, then +carefully consider how you will protect your application from the threats which +that defense parries.

+ + Propchange: db/derby/docs/trunk/src/security/csecintrosafer.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecintrothreats.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecintrothreats.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecintrothreats.dita (added) +++ db/derby/docs/trunk/src/security/csecintrothreats.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,83 @@ + + + + + +Threats to unsecured databases +A threat is potential damage caused by an attacker using a technique +to exploit a vulnerability. We have already seen examples of + vulnerabilities. +Examples of damages, attackers, and techniques follow. + + +

Significant damages include the following.

Denial-of-service attacks: An attacker can monopolize resources on +the host machine. For instance, an attacker can launch a runaway procedure on +the virtual machine, +fill up the file system, or pepper the + server with incessant +connection requests.
Theft: An attacker can read private information stored in a + database or transmitted +across the network. With enough privileges and by exploiting application code +visible on the classpath, an attacker can use + to read private +information stored elsewhere on the server machine or even on other machines +inside the firewall.
Corruption: An attacker can modify or destroy information stored in a + database or elsewhere +inside the firewall.

Attackers include the following.

Insiders: These are privileged persons who enjoy access to systems +inside the firewall and maybe even to restricted machine rooms. Drunken System +Administrators and disgruntled co-workers can cause significant damage.
Outsiders: These include politically motivated governments and +guerillas, commercially motivated businesses and criminals, and thrill-seeking +attackers.

Techniques of attack include the following.

SQL injection: This technique plagues applications that construct +queries by concatenating input from clients. A clever client can put SQL into +these fields. That SQL, not intended by the application, then runs inside the +database.
Man-in-the-middle: In this technique, the client believes that it is +talking to the server. In reality, the connection has been intercepted by +another machine. The device in the middle can examine and alter the +traffic.
Eavesdropping: This is a special case of the man-in-the-middle +attack. The attacker listens to the network traffic but does not interfere with +it. An example of this technique is password sniffing, in which a machine in the +middle intercepts the credentials handshake between client and server.
Malware: This is a general term for viruses, worms, trojan horses, +and other intrusive or destructive code that can infect a machine.
Probing: This is the technical equivalent of jiggling door handles to +see what doors are unlocked.
Physical access: This refers to the low-tech, brute-force technique +of gaining physical access to a restricted area or machine and, for instance, +exploiting superuser powers that might be available from a system's +console.
Social engineering: This refers to the low-tech technique of gaining +and abusing the confidence of someone who has the keys.

+ + Propchange: db/derby/docs/trunk/src/security/csecintrothreats.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecintrovuln.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecintrovuln.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecintrovuln.dita (added) +++ db/derby/docs/trunk/src/security/csecintrovuln.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,56 @@ + + + + + +Vulnerabilities of unsecured databases +If you do not configure + security, you must be +aware of the following vulnerabilities. + + +

Network JDBC: Network JDBC connections expose sensitive operations to +use by persons who may not have account privileges on the database machine.
Cleartext traffic: By default, network traffic travels in +cleartext.
Unbounded growth: Tables can grow arbitrarily large.
CPU hogging: Unbounded CPU cycles can be consumed by connection +attempts, SQL queries, and user code running in the database.
Superusers: By default, all +users enjoy extensive powers to read and write in all databases.
Launch privileges: + procedural code +executes with the operating system privileges of the account that launched the +virtual machine. This includes system-supplied procedures as well as custom, +user-coded procedures.
User code: Arbitrary user code can execute in the + virtual machine by +means of user-coded functions and procedures.
Open source: +'s code itself is +publicly visible as part of the + open source project. +This means that an attacker can write subtle malware after studying the code and +file formats. Note that while closed source code enjoys the advantage of +"security by obscurity", openness can confer other, countervailing security +advantages.

+ + Propchange: db/derby/docs/trunk/src/security/csecintrovuln.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecintrowhy.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecintrowhy.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecintrowhy.dita (added) +++ db/derby/docs/trunk/src/security/csecintrowhy.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,32 @@ + + + + + +Why databases need security +An unsecured database has numerous vulnerabilities to different kinds +of threats. + + +

This section does not provide a complete list of these vulnerabilities and +threats. No survey of security concerns can hope to be complete. However, this +section attempts to list the major vulnerabilities and threats known today.

The remainder of this guide describes how you can combat these threats.

+ + Propchange: db/derby/docs/trunk/src/security/csecintrowhy.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecjavadb.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecjavadb.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecjavadb.dita (added) +++ db/derby/docs/trunk/src/security/csecjavadb.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,59 @@ + + + + + +Relationship between Java DB and Apache +<ph conref="../conrefs.dita#prod/productshortname"></ph> +Java DB is a relational database management system that is based on +the Java programming language and SQL. Java DB is the Oracle release of the +Apache Derby project, the Apache Software Foundation's (ASF) open source +relational database project. + +Java DB and Derby +Derby and Java DB + + + +

The Java DB product includes + without any +modification whatsoever to the underlying source code.

Because Java DB and +have the same functionality, the Java DB documentation refers to the core +functionality as .

The Java DB +documentation is based +on the documentation. +References to "" in the +Java DB documentation should be understood as synonyms for "Java DB."

Oracle has made changes to the + documentation. This +manual is identical to the + Security +Guide, with the following exceptions:

Oracle has added this topic, "Relationship between Java DB and +".
In the titles of manuals, +"" has been changed to +"Java DB".

+ + Propchange: db/derby/docs/trunk/src/security/csecjavadb.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecjavasecurity.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecjavasecurity.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecjavasecurity.dita (added) +++ db/derby/docs/trunk/src/security/csecjavasecurity.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,125 @@ + + + + +Configuring Java security +The Java security manager lets you reduce the damage that your +application can do. + + + + +

Using a security manager, the System Administrator can restrict how an +application cooperates with other applications running in the same virtual +machine (VM) or elsewhere on the same machine. When you run + under a security +manager, you can restrict the following:

Backups: You control where the + engine writes and reads +database backup files.
Imports and exports: You control where the engine imports data from +and where it exports data to.
Jar files: You control where the engine obtains jar files of +customer-coded functions and procedures.
Sockets: You control what machines can connect to the server and +What machines the server can connect to.

To take advantage of these powerful controls, first customize a copy of the + security policy +template. You will find a template security policy in the + distribution at +demo/templates/server.policy.

shows this basic policy. It grants +permissions to both the derby.jar and +derbynet.jar codebases. To run + in embedded mode, you +must grant permissions to derby.jar. To run the + Network Server, you +must grant permissions to both derby.jar and +derbynet.jar.

shows a sample +customized policy file.

To customize the file, make the following edits:

URLs: Replace the ${derby.install.url} variables +with a URL pointing to the directory that holds the + jar files. For example: +file:///Users/me/javadb/lib/
System home: Look for instances of the string +${derby.system.home}. Replace them with the name of the +directory that holds your derby.properties file.
Tracing: Grant + the power to manage a +directory tree that will hold server trace information. Look for the +${derby.drda.traceDirectory} variable and replace it with the +directory where the server should write its diagnostic traces. For more +information on tracing, +see "Controlling tracing by using the trace facility" in the +.
Backups/imports/jars: Look for the first instance of the string +<<ALL FILES>>. Make two more copies of this line so that +there are three copies of this line in the file. On the first line, replace +<<ALL FILES>> with the directory tree that you will use +for holding database backups. For example: +/Users/me/backups +
Similarly, on the second line, replace <<ALL FILES>> +with the directory tree which you will use for staging imported/exported data. +On the third line, replace <<ALL FILES>> with the +directory tree that holds the jar files of functions and procedures that you +will load into databases. For the detailed syntax of these lines, see the +API documentation for java.io.FilePermission.
Sysinfo: The sysinfo logic appears redundantly in +several jar files: +derby.jar +derbynet.jar +derbyclient.jar +derbytools.jar +
If you want to run the sysinfo command, you will need to +grant permissions to the first of these jar files that appears in your +classpath.
+
If you are running + by using the command +java -jar derbyrun.jar, the first relevant jar file in the +classpath is derby.jar. The template policy file grants these +permissions to derbynet.jar. Note that the template policy file +grants sysinfo the privilege to read all files in the system. +You can restrict this to just the directory that contains the jar files wired +into your classpath.
Sockets: The template policy file accepts connection requests from +all hosts. You may want to restrict the template file's +java.net.SocketPermission to connections from a particular +subdomain. For details, see the API documentation for +java.net.SocketPermission. In addition, if you are using LDAP +authentication, then you must grant derby.jar the privilege to +connect to the LDAP server.

This manual does not describe the Java security manager in depth. For more +information, see . In particular, you may want to read the +Security Architecture paper () +and the Default Policy Implementation and Policy File Syntax information +().

+ + Propchange: db/derby/docs/trunk/src/security/csecjavasecurity.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecldapbooting.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecldapbooting.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecldapbooting.dita (added) +++ db/derby/docs/trunk/src/security/csecldapbooting.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,49 @@ + + + + + +Booting an LDAP server +To begin, launch the OpenDS QuickSetup JNLP (Java Web Start) +installer, then follow the installation steps to set up your directory +server. + + +LDAP directory servicebooting + + + +

You can obtain the installer from by clicking the +"Install with QuickSetup" link.

As part of this installation, you will specify a password, which we will +call YOUR_SELECTED_PASSWORD.

Next, load some credentials into the directory server. Download this sample +file of credentials: +. Now load it into your directory server using the +import-ldif tool in the bin directory of your +OpenDS installation. (Make sure that OpenDS is not running when you import +credentials; otherwise you will receive an error message indicating that the +import utility cannot acquire a lock over storage.)

+import-ldif --backendID userRoot --ldifFile secArticle.LDIF +

Now bring up the OpenDS server by running the start-ds +script in the bin directory of your OpenDS installation.

+ + Propchange: db/derby/docs/trunk/src/security/csecldapbooting.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecnativeconvert.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecnativeconvert.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecnativeconvert.dita (added) +++ db/derby/docs/trunk/src/security/csecnativeconvert.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,48 @@ + + + + + +Converting an existing database to use NATIVE authentication +If you wish to apply NATIVE authentication to a database that was +created without it, the procedure is slightly different depending on whether you +specify NATIVE:credentialsDB or +NATIVE:credentialsDB:LOCAL. + +user authenticationNATIVE authentication +NATIVE authenticationconverting a database to use + + + +

If you specify NATIVE:credentialsDB, add users of the existing +database to the credentialsDB. For instance, if the old database was +created without any authentication, then its default user name is APP, and you +could do the following: +CALL SYSCS_UTIL.SYSCS_CREATE_USER('app', 'app');
If you plan to specify NATIVE:credentialsDB:LOCAL, first connect to +the existing database as its +Database Owner using its old +authentication scheme. Call SYSCS_UTIL.SYSCS_CREATE_USER to add +credentials for the Database Owner. For example, if the existing database was +created with no authentication, the Database Owner is APP, and you would add +credentials for APP as shown above.

+ + Propchange: db/derby/docs/trunk/src/security/csecnativeconvert.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecnativecreddb.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecnativecreddb.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecnativecreddb.dita (added) +++ db/derby/docs/trunk/src/security/csecnativecreddb.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,59 @@ + + + + + +Working with a credentials database +With NATIVE authentication, a database can become a credentials +database in any of several ways. + +user authenticationNATIVE authentication +NATIVE authenticationcredentials database + + + +

When the database is being created, it is identified as the credentials +database by the system-level property setting +derby.authentication.provider=NATIVE:credentialsDB.
When the database is being created, LOCAL authentication of connections is +specified by the system-level property setting +derby.authentication.provider=NATIVE:credentialsDB:LOCAL.
When the database already exists, the +Database Owner calls the +SYSCS_UTIL.SYSCS_CREATE_USER system procedure to store the +Database Owner's credentials in the database. If the Database Owner calls this +procedure to store another user's credentials first, an error is raised.

When a database becomes a credentials database, the following things +happen:

The value of derby.authentication.provider=NATIVE::LOCAL +is stored in the database, marking it as a credentials database.
From this point forward, the value of +derby.authentication.provider cannot be overridden or changed +for connections to this database.
If the database is being newly created, the Database Owner's credentials +(provided in the connection arguments) are stored in the database's SYSUSERS +system table.
All future connections to the database are authenticated against the +credentials in its SYSUSERS system table.

+ + Propchange: db/derby/docs/trunk/src/security/csecnativecreddb.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecnativeenable.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecnativeenable.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecnativeenable.dita (added) +++ db/derby/docs/trunk/src/security/csecnativeenable.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,60 @@ + + + + + +Enabling NATIVE authentication explicitly +You can turn on NATIVE authentication explicitly by using a +property. + +user authenticationNATIVE authentication +NATIVE authenticationenabling + + + +

To do so, specify one of the following values for the +derby.authentication.provider property:

NATIVE:credentialsDB +
This value tells to +use credentialsDB, a dedicated database, to store user credentials. This +value must be set by using system-wide Java Virtual Machine (JVM) properties or +by using the derby.properties file; it cannot be set in the +database by using the SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY +procedure. When this system-wide value is set, credentialsDB is used to +authenticate all operations. If an individual database holds credentials for the +Database Owner, the global +credentials database is used only to authenticate system-wide operations such as +engine shutdown.
+
The value of credentialsDB must be a valid name for a database.
+
NATIVE:credentialsDB:LOCAL +
This value tells to +use credentialsDB for system-wide operations, but to use an individual +database's SYSUSERS system table to authenticate connections to that database. +This value must be set by using system-wide JVM properties or by using the +derby.properties file; it cannot be set in the database by +using the SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY system +procedure.
+

See the for details on the +derby.authentication.provider property.

+ + Propchange: db/derby/docs/trunk/src/security/csecnativeenable.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecnativemanagecreds.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecnativemanagecreds.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecnativemanagecreds.dita (added) +++ db/derby/docs/trunk/src/security/csecnativemanagecreds.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,54 @@ + + + + + +Managing users and passwords +To manage users and passwords, + provides a group of +system procedures. + +user authenticationNATIVE authentication +NATIVE authenticationmanaging credentials + + + +

To create users for a database, the +Database Owner calls +SYSCS_UTIL.SYSCS_CREATE_USER, which takes a user name and +password as arguments. This procedure can also be executed by a user or role +to which the Database Owner has granted sufficient privileges.
To remove a user, the Database Owner calls +SYSCS_UTIL.SYSCS_DROP_USER, which takes one argument, +the user name of the user. This procedure can also be executed by a user or role +to which the Database Owner has granted sufficient privileges.
To reset a forgotten or expired password, the Database Owner calls +SYSCS_UTIL.SYSCS_RESET_PASSWORD, with a user name and +password as arguments. This procedure can also be executed by a user or role +to which the Database Owner has granted sufficient privileges.
To change a user's own password, any user can call the system procedure +SYSCS_UTIL.SYSCS_MODIFY_PASSWORD, which takes only one +argument, the password. Typically, a user calls this procedure when their +password is about to expire.

See the for details on these +procedures.

+ + Propchange: db/derby/docs/trunk/src/security/csecnativemanagecreds.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecnativeotherprops.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecnativeotherprops.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecnativeotherprops.dita (added) +++ db/derby/docs/trunk/src/security/csecnativeotherprops.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,64 @@ + + + + + +NATIVE authentication and other database properties +When NATIVE authentication is enabled, + behaves as if the +derby.connection.requireAuthentication and +derby.database.sqlAuthorization properties are also +set. + +user authenticationNATIVE authentication +NATIVE authenticationand other database properties + + + +

That is, a user name and password must be specified whenever a user connects +to a database, and object owners control access to database objects. See + for more information, +and see + for an example of the use of NATIVE +authentication.

For maximum security, the passwords that users specify when they connect to +databases have an expiration date that you can modify by using the property +derby.authentication.native.passwordLifetimeMillis. The +password of the +Database Owner never expires. By +default, ordinary user passwords expire after 31 days.

If a password is about to expire, or if the Database Owner's password is +near what would be the expiration date, + issues a warning that +the password will soon expire (or, in the Database Owner's case, that the +password is stale). By default, the warning is issued if the password is due to +expire in one-eighth of the password's lifetime. For example, if the password +has a 31-day lifetime, the warning will be issued 3.875 days before the +expiration date. You can change this proportion by using the property +derby.authentication.native.passwordLifetimeThreshold.

Use the derby.authentication.builtin.algorithm property to +change the way passwords are encrypted when they are stored in the SYSUSERS +system table. The default algorithm is SHA-256. Two related properties are +derby.authentication.builtin.saltLength and +derby.authentication.builtin.iterations, which can be used to +make the hashed passwords harder for attackers to crack.

See the for details on these +properties.

+ + Propchange: db/derby/docs/trunk/src/security/csecnativeotherprops.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecnetservauthent.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecnetservauthent.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecnetservauthent.dita (added) +++ db/derby/docs/trunk/src/security/csecnetservauthent.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,31 @@ + + + + + +Configuring Network Server authentication in special circumstances +Some advanced Network Server configuration features may be useful in +certain situations. + +Network Server authenticationconfiguring + + + + + Propchange: db/derby/docs/trunk/src/security/csecnetservauthent.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecnetservfileperms.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecnetservfileperms.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecnetservfileperms.dita (added) +++ db/derby/docs/trunk/src/security/csecnetservfileperms.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,130 @@ + + + + +Restricting file permissions +Additional file protections are available on some file systems, +including Windows NTFS, Unix, and Linux. If you are running a Java 7 or higher +VM, you can configure +to take advantage of these extra file protections. + +derby.storage.useDefaultFilePermissions property +database filesspecifying permissions with Java SE 7 and up +file permissionsspecifying with Java SE 7 and up +permissionsfile, specifying with Java SE 7 and up + + + +

By default, creates +new directories and files with the default permissions of the operating system +account that started the VM (the umask setting on Unix and Linux). You can +configure to override +those default permissions and to restrict access to just that account. If you +configure this way, +only that account can access the directories and files created by +. If you are running on +a Java 7 or higher VM, you can configure this extra protection by setting the +following system property, either on the VM command line or in +derby.properties:

+derby.storage.useDefaultFilePermissions=false +

For more information, see "derby.storage.useDefaultFilePermissions" in +the .

If you set this property, other operating system accounts will have no access +to directories or files created by +. This behavior can be +helpful in enhancing default security for database files.

The exact behavior is determined by two factors: how the + engine is started, and +the presence or absence and specified value of the property +derby.storage.useDefaultFilePermissions.

The two tables that follow show how file access works with Java SE 7 and +later JVMs and with Java SE 6. In both tables,

"Environment" means that access is controlled entirely by the JVM +environment and the file location only (that is, by the umask setting on UNIX +and Linux systems and by the default file permissions on Windows NTFS).
"Restricted" means that + restricts access to the +operating system account that started the JVM.

The following table shows how file access works on Java SE 7 and later +systems with various settings of the +derby.storage.useDefaultFilePermissions property.

+ +File access on Java SE 7 and later systems +This table shows how access to files is controlled on Java SE 7 and later systems. + + + + + + +Property Setting +Server Started from Command Line +Server Started Programmatically or Embedded + + + + +No property specified +Restricted +Environment + + +Property set to true +Environment +Environment + + +Property set to false +Restricted +Restricted + + + +

The following table shows how file access works on Java SE 6 systems.

+ +File access on Java SE 6 systems +This table shows how access to files is controlled on Java SE 6 systems. + + + + + + +Property Setting +Server Started from Command Line +Server Started Programmatically or Embedded + + + + +Not applicable +Environment +Environment + + + +

If you are running on a Java 6 or earlier VM, then you may want to adjust +your account's default file permissions before using +.

+ + Propchange: db/derby/docs/trunk/src/security/csecnetservfileperms.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecnetservsecurity.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecnetservsecurity.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecnetservsecurity.dita (added) +++ db/derby/docs/trunk/src/security/csecnetservsecurity.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,57 @@ + + + + +Network Server security +By default, the + Network Server listens +only on the localhost. Clients must use the localhost host name to +connect. + +Network Server securityNetwork +Serverand security changes + + +

By default, clients cannot access the Network Server from another host. To +enable connections from other hosts, set the derby.drda.host +property, or start the Network Server with the -h option +in the java org.apache.derby.drda.NetworkServerControl start +command.

In the following example, the server will listen only on the localhost, and +clients cannot access the server from another host:

+java org.apache.derby.drda.NetworkServerControl start +

In the following example, the server runs on the host machine +sampleserver.example.com and also listens for clients +from other hosts. Clients must specify the server in the URL or DataSource as +sampleserver.example.com:

+java org.apache.derby.drda.NetworkServerControl start \ +-h sampleserver.example.com +

To start the Network Server so that it will listen on all interfaces, start +with an IP address of 0.0.0.0, as shown in the following +example:

+java org.apache.derby.drda.NetworkServerControl start -h 0.0.0.0 +

A server that is started with the -h 0.0.0.0 option will +listen to client requests that originate from both localhost +and from other machines on the network.

However, administrative commands (for example, +org.apache.derby.drda.NetworkServerControl shutdown) can run +only on the host where the server was started, even if the server was started +with the -h option.

+ + Propchange: db/derby/docs/trunk/src/security/csecnetservsecurity.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecpref11181.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecpref11181.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecpref11181.dita (added) +++ db/derby/docs/trunk/src/security/csecpref11181.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,35 @@ + + + + + +Purpose of this guide +This guide provides information on securing + databases. + + +

provides several ways +to protect the correctness and privacy of your data as well as to prevent +accidental or malicious misuse of the database software itself. This guide +explains how to improve the database security of applications and machines that +use . It describes how +to configure security for both embedded applications and applications that use +the Network Server.

+ + Propchange: db/derby/docs/trunk/src/security/csecpref11181.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecpref23947.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecpref23947.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecpref23947.dita (added) +++ db/derby/docs/trunk/src/security/csecpref23947.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,74 @@ + + + + + +How this guide is organized +This guide includes the following two parts. + + +

Part One: Introduction to database security

+
Describes the vulnerabilities and threats that databases face.
+
Describes the kinds of defenses that databases can use.
+
Shows how the defenses available to databases map to the threats that they +face.
+
Describes important techniques for securing databases.
+
Provides a glossary of security terms used in this part.

Part Two: Configuring security for +

+
Lists basic tasks for configuring security in an embedded or client/server +environment.
+
Explains how to encrypt +databases.
+
Explains how to use signed jar files in + databases.
+
Explains how to use SSL/TLS to encrypt network traffic in a client/server +environment.
+
Describes the concepts of identity, users, and authorization identifiers in +.
+
Explains how to configure authentication, which determines whether someone is +a legal user.
+
Explains how to configure authorization, which determines what operations can +be performed by a user's identity.
+
Explains how to use a Java security manager with +.
+
Explains how to take advantage of file system protections.
+
Shows how to enable all the available + defenses.

+ + Propchange: db/derby/docs/trunk/src/security/csecpref23947.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecpref24290.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecpref24290.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecpref24290.dita (added) +++ db/derby/docs/trunk/src/security/csecpref24290.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,31 @@ + + + + + +Audience +This guide is intended for software developers who already know +some SQL and Java. + + +

users who are +not familiar with the SQL standard or the Java programming language will benefit +from consulting books on those subjects.

+ + Propchange: db/derby/docs/trunk/src/security/csecpref24290.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecpref29520.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecpref29520.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecpref29520.dita (added) +++ db/derby/docs/trunk/src/security/csecpref29520.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,38 @@ + + + + + +About this guide + + +

For general information about the + documentation, such as +a complete list of books, conventions, and further reading, see +.

For more information about +, visit the + website at +. +The website provides pointers to the + Wiki and other +resources, such as the derby-users mailing list, where you can ask questions +about issues not covered in the documentation.

+ + Propchange: db/derby/docs/trunk/src/security/csecpref29520.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecputrun.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecputrun.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecputrun.dita (added) +++ db/derby/docs/trunk/src/security/csecputrun.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,119 @@ + + + + + +Creating and using a secure database +Now the Database Owner creates an encrypted database, turns on +coarse-grained authorization, and creates some data that everyone can read but +only he can write. + +

Fine-grained authorization is automatically turned on because we are using +NATIVE authentication.

Connection URLs are shown on multiple lines, but must be entered on one +line.

+java -Djavax.net.ssl.trustStore=/Users/me/vault/ClientTrustStore \ +-Djavax.net.ssl.trustStorePassword=secretClientTrustStorePassword \ +-Djavax.net.ssl.keyStore=/Users/me/vault/ClientKeyStore \ +-Djavax.net.ssl.keyStorePassword=secretClientPassword \ +org.apache.derby.tools.ij +ij version 10.9 +ij> connect 'jdbc:derby://localhost:8246/mchrystaEncryptedDB;create=true; +user=mchrysta;password=mchrysta;dataEncryption=true; +encryptionAlgorithm=Blowfish/CBC/NoPadding; +bootPassword=mySuperSecretBootPassword;ssl=peerAuthentication'; +ij> -- +-- Prevent our authentication properties from being overridden on the +-- command line or in derby.properties. +-- +call SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY +( 'derby.database.propertiesOnly','true'); +Statement executed. +ij> -- +-- This time around, there is no need to add credentials for the database +-- owner. That is because the database owner's credentials were +-- automatically added when we created the NATIVE database, advertised to +-- the server by setting +-- -Dderby.authentication.provider=NATIVE:mchrystaEncryptedDB. +-- +--call SYSCS_UTIL.SYSCS_CREATE_USER( 'mchrysta', 'mchrysta' ); + +-- now add other users +call SYSCS_UTIL.SYSCS_CREATE_USER( 'thardy', 'thardy' ); +Statement executed. +ij> call SYSCS_UTIL.SYSCS_CREATE_USER( 'jhallett', 'jhallett' ); +Statement executed. +ij> call SYSCS_UTIL.SYSCS_CREATE_USER( 'tquist', 'tquist' ); +Statement executed. +ij> -- +-- Turn on coarse-grained authorization +-- +call SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY +( 'derby.database.fullAccessUsers', 'tquist,mchrysta' ); +Statement executed. +ij> call SYSCS_UTIL.SYSCS_SET_DATABASE_PROPERTY +( 'derby.database.readOnlyAccessUsers', 'thardy,jhallett' ); +Statement executed. +ij> -- +-- Shut down the database and bring it back up. This will turn on NATIVE +-- authentication and fine-grained authorization. +-- +connect 'jdbc:derby://localhost:8246/mchrystaEncryptedDB;shutdown=true; +user=mchrysta;password=mchrysta;ssl=peerAuthentication'; +ERROR 08006: DERBY SQL error: SQLCODE: -1, SQLSTATE: 08006, SQLERRMC: +Database 'mchrystaEncryptedDB' shutdown. +ij> -- +-- Reboot the encrypted, password-protected database. +-- +connect 'jdbc:derby://localhost:8246/mchrystaEncryptedDB;user=mchrysta; +password=mchrysta;bootPassword=mySuperSecretBootPassword; +ssl=peerAuthentication'; +ij(CONNECTION1)> -- +-- Create some data and let everyone see it. +-- +create table mchrysta.t1( a varchar( 20 ) ); +0 rows inserted/updated/deleted +ij(CONNECTION1)> insert into mchrysta.t1( a ) values ( 'mchrysta' ); +1 row inserted/updated/deleted +ij(CONNECTION1)> grant select on table mchrysta.t1 to public; +0 rows inserted/updated/deleted +ij(CONNECTION1)> -- +-- Verify that another user can read the newly created data but not write +-- it: +-- +connect 'jdbc:derby://localhost:8246/mchrystaEncryptedDB;user=tquist; +password=tquist;ssl=peerAuthentication'; +ij(CONNECTION2)> -- +-- Verify that this user can see the data ... +-- +select * from mchrysta.t1; +A +-------------------- +mchrysta + +1 row selected +ij(CONNECTION2)> -- +-- ... but not write the data: +-- +insert into mchrysta.t1( a ) values ( 'tquist' ); +ERROR 42500: User 'TQUIST' does not have INSERT permission on table +'MCHRYSTA'.'T1'. + + + Propchange: db/derby/docs/trunk/src/security/csecputrun.dita ------------------------------------------------------------------------------ svn:eol-style = native Added: db/derby/docs/trunk/src/security/csecputstart.dita URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecputstart.dita?rev=1596037&view=auto ============================================================================== --- db/derby/docs/trunk/src/security/csecputstart.dita (added) +++ db/derby/docs/trunk/src/security/csecputstart.dita Mon May 19 20:09:33 2014 @@ -0,0 +1,44 @@ + + + + + +Starting a secured Network Server +Bring up the server, turning on SSL and Java security. + +

This example uses the customized security policy shown in +. The command line +first brings up the server, turning on SSL and Java Security. It also tells the +server that NATIVE credentials will be stored in the +mchrystaEncryptedDB database. That last directive causes the +Database Owner's credentials to be +stored when mchrystaEncryptedDB is +created.

+java -Djavax.net.ssl.keyStore=/Users/me/vault/ServerKeyStore \ +-Djavax.net.ssl.keyStorePassword=secretServerPassword \ +-Djavax.net.ssl.trustStore=/Users/me/vault/ServerTrustStore \ +-Djavax.net.ssl.trustStorePassword=secretServerTrustStorePassword \ +-Dderby.storage.useDefaultFilePermissions=false \ +-Dderby.authentication.provider=NATIVE:mchrystaEncryptedDB \ +-Djava.security.manager \ +-Djava.security.policy=/Users/me/myServer.policy \ +org.apache.derby.drda.NetworkServerControl start -p 8246 \ +-ssl peerAuthentication + +