Baguette/dodb.cr
3
0
Fork 1
Code Issues Pull Requests Releases Wiki Activity

Blah.

Browse Source
This commit is contained in:
Philippe PITTOLI 2024-05-19 18:09:19 +02:00
parent ef92be31cc
commit 58d7147752
2 changed files with 22 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
graphs/graphs.ms
View File

@ -883,7 +883,7 @@ This is not acceptable for databases with large partitions and tags: memory will
Right now, security isn't managed in DODB, at all.
Sure, DODB isn't vulnerable to SQL injections, but an internet-facing application may encounter a few other problems including, but not limited to, code injection, buffer overflows, etc.
Of course, DODB isn't a mechanism to protect applications from any possible attack, so most of the vulnerabilities cannot be countered by the library.
However, a few security mechanisms exist to prevent data leak or data modification from an outsider, and the DODB library should implement some of them in the future.
However, a few security mechanisms exist to prevent data leak or data modification from an outsider and the DODB library may implement some of them in the future.
.B "Preventing data leak" .
Since DODB is a library, any attack on the application using it can lead to a data leak.
@ -891,15 +891,31 @@ For the moment, any part of the application can access data stored in memory.
Operating systems provide system calls to protect parts of the allocated memory.
For instance,
.FUNCTION_CALL mlock
prevents a region of memory from being put in the swap, which may lead to a data leak.
Also,
prevents a region of memory from being put in the swap because it could lead to a data leak.
The
.FUNCTION_CALL madvise
syscall can prevent parts of the application's memory to be put in a code-dump\*[*], which is a debug file created when an application crashes containing (part of) the process's memory when it crashed.
.FOOTNOTE1
.FUNCTION_CALL madvice
has the interesting option
.I MADV_DONTDUMP
to prevent a data leak through a core-dump, but it is linux-specific.
.FOOTNOTE2
In a running process,
.FUNCTION_CALL mprotect
prevents the application itself to access part of its own memory;
the idea is to read (or write) memory only once you ask for it via a syscall, so you cannot access it from anywhere by mistake (or after an attack).
.TBD
the idea is to read (or write) memory only once you ask for it via a syscall.
Thus, you cannot access data from anywhere (by mistake or after an attack).
.B "Discussion on security, not related to DODB" .
These mechanisms could be used internally by DODB to prevent a data leak since memory is handled by the library.
However, the Crystal language doesn't provide a way to manage memory manually and this may be a problem for mlock and mprotect.
Depending on the plateform (the operating system), these syscalls may require the memory to be aligned with the memory pages.
Thus, the implementation won't be easy.
.B "Side-note. Discussion on security" .
No authorization mechanism prevents the application to access un-authorized data, including, but not limited to, any file on the file-system.
Since this implementation of DODB is related to the Crystal language (which isn't fully ported to the OpenBSD plateform at-the-moment), this is a problem.
.
.
.SECTION Conclusion

2
src/dodb.cr
View File

@ -109,7 +109,6 @@ abstract class DODB::Storage(V)
hash
end
##
# name is the name that will be used on the file system.
def new_index(name : String, &block : Proc(V, String) | Proc(V, String | DODB::NoIndex))
CachedIndex(V).new(self, @directory_name, name, block).tap do |indexer|
@ -135,7 +134,6 @@ abstract class DODB::Storage(V)
index.not_nil!.as(DODB::Index).get key
end
##
# name is the name that will be used on the file system.
def new_partition(name : String, &block : Proc(V, String) | Proc(V, String | DODB::NoIndex))
CachedPartition(V).new(self, @directory_name, name, block).tap do |table|