Drizzle: a lighter MySQL

Posted Jul 24, 2008 3:40 UTC (Thu) by Sutoka (guest, #43890)
In reply to: Drizzle: a lighter MySQL by elanthis
Parent article: Drizzle: a lighter MySQL

I believe by 'secure' he was referring to the point that it isn't running as a daemon that
could potentially be exposed to other systems on the network (sane defaults by the distros
could mitigate the risk some).

Also, if theres one central PostgreSQL/MySQL server running on the system for all the desktop
users, an exploit in the server would expose other user's data which wouldn't be possible if
each application simply used an SQLite database stored under ~.

In my OP I was more so thinking about something a little higher than SQLite, without being as
high as the traditional DBMSs. If the 'server' was per-user, and connected to the user's other
applications by something that is already supposed to be trusted (like DBus's session bus?),
it could help ensure the SQLite db isn't lost as easily (say, keeping a copy around from the
end of the last session as well as a transaction log?).

Then again, what do I know? I (obviously :P) have little experience with these database
systems, and none from a development PoV.

Drizzle: a lighter MySQL

Posted Jul 24, 2008 5:25 UTC (Thu) by louie (guest, #3285) [Link] (3 responses)

Yeah, that's what I meant. If my application is compromised, or my file system is compromised,
then my data is hosed, whether it is in SQLite or mysql (or any other storage technique that I
know of). Agreed that sqlite doesn't add any layers of security there. The mysql daemon (any
database server, really) adds another attack vector, which as we all know is often exploited.
So given the lack of a daemon I think it is reasonable to say that sqlite is a more secure
solution.

Drizzle: a lighter MySQL

Posted Jul 24, 2008 7:46 UTC (Thu) by jamesh (guest, #1159) [Link] (2 responses)

There are varying levels at which an application can be compromised.  An attacker may work out
a way to run arbitrary SQL but not arbitrary code (an SQL injection attack).  In this case,
limiting what SQL can be executed will reduce the impact of the vulnerability even if the
database files are owned by the user running the application.

Drizzle: a lighter MySQL

Posted Jul 24, 2008 16:30 UTC (Thu) by louie (guest, #3285) [Link] (1 responses)

Unless you're djb, your software inevitably accrues features and picks up security problems as
a result. So I would never rely on 'my software is more secure because it does less.'

Drizzle: a lighter MySQL

Posted Jul 25, 2008 4:13 UTC (Fri) by jamesh (guest, #1159) [Link]

It isn't so much doing less as compartmentalising the code.  Programmers will make mistakes,
so doesn't it make sense to limit the damage that can occur when such a mistake is made?

If you have an SQL injection vulnerability, why does it have to be a data loss problem (if the
attacker can issue DROP TABLE) when it could just be information disclosure (and even that can
be limited).

And if we ignore the security aspect, restricting what an application can do can help pick up
programming errors.  If you have a log analysis application, it might only need to read from a
set of tables and not write to any tables.  Giving it only those permissions makes it obvious
if those expectations aren't met.