Bug 1543569

Err, I confused expected result and actual result.

Actual results:
avc:  denied  { write } for  pid=43643 comm="httpd" name="cert9.db" dev="dm-0" ino=163181 scontext=system_u:system_r:httpd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file permissive=1

Expected results:
no AVC

This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

The bug is no longer reproducible with freeIPA because freeIPA has replaced mod_nss with mod_ssl. Other users of mod_nss are most likely still affected.

Kai, 

Do you know whats going on here? 

From Description:
"I suspect that mod_nss or NSS opens the database for writing. Maybe sqlite does some locking? Rob or Kai might know." 

Yes, also think that NSS opens db for writing. Is it really necessary? I don't like idea to allow httpd_t domain to write to cert_t files. 

Thanks,
Lukas.

It might be sqlite. The libraries tries to open the file for reading. Here is a simplified example:

$ mkdir /tmp/testdb
$ sqlite3 /tmp/testdb/test.db -line 'create table memos(text, priority INTEGER);'
$ chmod a-w /tmp/testdb/ /tmp/testdb/test.db
$ strace -e file sqlite3 /tmp/testdb/test.db -line 'select * from memos;'
execve("/usr/bin/sqlite3", ["sqlite3", "/tmp/testdb/test.db", "-line", "select * from memos;"], 0x7ffebde06e78 /* 91 vars */) = 0
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libreadline.so.7", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libncurses.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libtinfo.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
access("/tmp/testdb/test.db", F_OK)     = 0
lstat("/tmp/testdb/test.db", {st_mode=S_IFREG|0444, st_size=8192, ...}) = 0
stat("/tmp/testdb/test.db", {st_mode=S_IFREG|0444, st_size=8192, ...}) = 0
openat(AT_FDCWD, "/tmp/testdb/test.db", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/tmp/testdb/test.db", O_RDONLY|O_CLOEXEC) = 3
stat("/tmp/testdb/test.db", {st_mode=S_IFREG|0444, st_size=8192, ...}) = 0
open("/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/lib64/libnss_sss.so.2", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/var/lib/sss/mc/passwd", O_RDONLY|O_CLOEXEC) = 4
openat(AT_FDCWD, "/home/heimes/.sqliterc", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/tmp/testdb/test.db-journal", 0x7ffe2e3e8690) = -1 ENOENT (No such file or directory)
stat("/tmp/testdb/test.db-wal", 0x7ffe2e3e8690) = -1 ENOENT (No such file or directory)
stat("/tmp/testdb/test.db-journal", 0x7ffe2e3e99f0) = -1 ENOENT (No such file or directory)
stat("/tmp/testdb/test.db-wal", 0x7ffe2e3e99f0) = -1 ENOENT (No such file or directory)
stat("/tmp/testdb/test.db", {st_mode=S_IFREG|0444, st_size=8192, ...}) = 0
+++ exited with 0 +++

Err, I meant "sqlite first tries to open the db for writing".

Sorry for the delay. We discovered that NSS never attempts to open the sqlite database in read only mode, even if the application asks for read-only mode.

See the following upstream bug for more details:
https://bugzilla.mozilla.org/show_bug.cgi?id=1449169

We should change NSS to use a newer sqlite API, that will allow the read-only opening, and should avoid changes to selinux.

We are late in the development cycle for Fedora 28. The final freeze is in 4 days, April 17.

Do you think it's acceptable if we fix this in a regular nss-softokn.rpm update, after the Fedora 28 release?

FreeIPA 4.7 no longer uses mod_nss. Therefore we are not affected by the bug any more. I ran into the issue during an early alpha release. Other users of mod_nss are still affected, though. I'm including Rob.

I don't know if it's acceptable to fix the issue after F28 is released. Adam Williamson may know.

(In reply to Christian Heimes from comment #9)
> I don't know if it's acceptable to fix the issue after F28 is released. Adam
> Williamson may know.

I don't think this would warrant being a blocker. I'm ok with fixing it ASAP once F28 is released.

Do we know whether the denial results in mod_nss getting read-only access to the DB, or not getting *any* access?

mod_nss opens the database exclusively read only by passing the NSS_INIT_READONLY to NSS_Initialize. It never opens it read/write.

That's what it *tries* to do, but the problem is explained in https://bugzilla.redhat.com/show_bug.cgi?id=1543569#c7 and in more detail in https://bugzilla.mozilla.org/show_bug.cgi?id=1449169 - mod_nss asks NSS to open the database read-only, but NSS does not actually honor that request from mod_nss.

What I'm asking is, when NSS does the wrong thing and hits this denial, does that prevent it accessing the DB entirely, or just mean it works fine (i.e. we get read access) but a meaningless AVC shows up?

Unknown, I only tried to run mod_nss in permissive mode and got the AVC.

NSS/SQLite fall back to read-only opening. So, if read-only access was intended, the app gets what it wants on the automatic fallback performed by SQLIte, after having gotten the denial.

OK. So the only real consequence here is the AVC getting generated. That's the info I was looking for, thanks.

Kai, I guess this can be closed now (as upstream fix was landed in 3.37)?

Sounds good.

Christian, please let us know if you still see a problem.