From 3109ee3bbaa33485594ee91f817319649c901023 Mon Sep 17 00:00:00 2001 From: Philippe Pittoli Date: Thu, 23 Jan 2025 04:17:14 +0100 Subject: [PATCH] Data-leak++ --- paper/paper.ms | 49 +++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 39 insertions(+), 10 deletions(-) diff --git a/paper/paper.ms b/paper/paper.ms index 6fe29a2..3709977 100644 --- a/paper/paper.ms +++ b/paper/paper.ms @@ -28,9 +28,9 @@ .I "\\$*" .. .de DIRECTORY -.ps -2 -.I "\\$*" -.ps +2 +.ps -3 +\f[CW]\\$*\f[] +.ps +3 .. .de PRIMARY_KEY .I \\$1 \\$2 \\$3 @@ -998,7 +998,7 @@ Sure, DODB isn't vulnerable to SQL injections, but an internet-facing applicatio 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 may implement some of them in the future. -.B "Preventing data leak" . +.B "Preventing data leak with in-app memory management" . Since DODB is a library, any attack on the application using it can lead to a data leak. 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. @@ -1022,17 +1022,46 @@ 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). 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\*[*]. +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 in the current state of affairs\*[*] (read: with the current Crystal's standard library). .FOOTNOTE1 But again, the Crystal language is an implementation detail. The working principle of DODB can be translated in basically any other language, including some enabling access to low-level memory operations. .FOOTNOTE2 -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. +.B "Other methods to prevent data leak" . +By default, a running application can call any syscall and open sockets or any file owned by the user. +Thus, in case a user runs an internet-facing application that is hacked, the content of any of their file can be leaked, including sensible files (in the +.DIRECTORY ~/.ssh/ +directory for example). + +To prevent applications from performing unwanted operations (calling syscalls or accessing some files unrelated to the proper functioning of the application), operating systems implemented specific ways to enforce security. +All of these methods have their own pros and cons. +This obviously goes beyond the scope of this document, but let's mention a few widespread mechanisms\*[*]. +.FOOTNOTE1 +Actual statistics on the use of the different security mechanisms is rather hard to obtain. +Both presented mechanisms are supported by a wealthy company or by the operating system itself. +.FOOTNOTE2 +.BULLET "\fBAppArmor\f[] (linux):" +Linux has many mechanisms to handle software security, one of the most known is AppArmor (supported since 2009 by Canonical). +AppArmor can limit the use of syscalls and the access to files and directories. +A configuration file is used to describe what an application (defined by the path to its executable) can or cannot do; the source code of the application is left untouched. + +.BULLET "\fBpledge and unveil\f[] (openbsd):" +The OpenBSD operating system includes two complementary syscalls: pledge (to allow or to deny use of syscalls) and unveil (to allow or to deny the access of directories and files). +The design of these functions is simple: applications often have an +.I init +phase during which the connections are made or files are opened (including configuration files), +then comes the +.I running +phase, during which the application needs less priviledges. +Therefore, an application can access whatever it needs for its initialization phase, then restricts its own rights over syscalls and files. +For example, a web server can read its configuration file to learn where are the files to serve, then prevents itself from accessing any other file (including its own configuration file). + +Having in-app mechanisms such as these greatly simplifies the configuration; and they are even inherently safer than AppArmor and the like. + +.ENDBULLET . . .SECTION Real-world usage: netlib.re