Thread: More sepgsql weirdness

More sepgsql weirdness

From
Dave Page
Date:
On a system with selinux and sepgsql configured, search path resolution appears to fail if sepgsql is in enforcing mode, but selinux is in permissive mode (which, as I understand it, should cause sepgsql to behave as if it's in permissive mode anyway - and does for other operations). Regardless of whether my understanding of the interaction of the two permissive modes is correct, I don't believe the following should happen:

mls=# SELECT current_user;

 current_user 

--------------

 postgres

(1 row)


mls=# SHOW search_path;

   search_path   

-----------------

 "$user", public

(1 row)


mls=# \dn+ public

                          List of schemas

  Name  |  Owner   |  Access privileges   |      Description       

--------+----------+----------------------+------------------------

 public | postgres | postgres=UC/postgres+| standard public schema

        |          | =UC/postgres         | 

(1 row)


mls=# CREATE TABLE tb_users(uid int primary key, name text, mail text, address text, salt text, phash text);

ERROR:  no schema has been selected to create in

LINE 1: CREATE TABLE tb_users(uid int primary key, name text, mail t...

                     ^

mls=# CREATE TABLE public.tb_users(uid int primary key, name text, mail text, address text, salt text, phash text);

CREATE TABLE

mls=# drop table tb_users;

ERROR:  table "tb_users" does not exist

mls=# drop table public.tb_users;

DROP TABLE


This is on head, pulled yesterday.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: http://www.enterprisedb.com

Re: More sepgsql weirdness

From
Robert Haas
Date:
On Tue, Apr 13, 2021 at 10:33 AM Dave Page <dpage@pgadmin.org> wrote:
> On a system with selinux and sepgsql configured, search path resolution appears to fail if sepgsql is in enforcing
mode,but selinux is in permissive mode (which, as I understand it, should cause sepgsql to behave as if it's in
permissivemode anyway - and does for other operations). Regardless of whether my understanding of the interaction of
thetwo permissive modes is correct, I don't believe the following should happen: 

I agree that this sounds like something which shouldn't happen if the
system is in permissive mode, but I think the behavior itself is
deliberate. See OAT_NAMESPACE_SEARCH and commit
e965e6344cfaff0708a032721b56f61eea777bc5.

--
Robert Haas
EDB: http://www.enterprisedb.com



Re: More sepgsql weirdness

From
Dave Page
Date:
Hi

On Tue, Apr 13, 2021 at 6:22 PM Robert Haas <robertmhaas@gmail.com> wrote:
On Tue, Apr 13, 2021 at 10:33 AM Dave Page <dpage@pgadmin.org> wrote:
> On a system with selinux and sepgsql configured, search path resolution appears to fail if sepgsql is in enforcing mode, but selinux is in permissive mode (which, as I understand it, should cause sepgsql to behave as if it's in permissive mode anyway - and does for other operations). Regardless of whether my understanding of the interaction of the two permissive modes is correct, I don't believe the following should happen:

I agree that this sounds like something which shouldn't happen if the
system is in permissive mode,

I realised that my test database hadn't had the sepgsql SQL script run in it (I must have created it before running it on template1). I guess the error was caused by lack of proper labelling.

So, clearly my fault, but I think there are a couple of things we need to do here:

1) Improve the docs for sepgsql. The *only* vaguely useful source of info I've found on using this is "SELinux System Administration", a Packt book by Sven Vermeulen. Our own docs don't even list the supported object classes (e.g. db_table) or types (e.g. sepgsql_ro_table_t) for example.

2) Improve the way we handle cases like the one I ran into. I only realised what was going on when I tried to run sepgsql_getcon() to confirm I was running in undefined_t. Clearly very weird things can happen if labelling hasn't been run; perhaps we could raise a notice if the sepgsql module is loaded but sepgsql_getcon() isn't present (though that seems flakey at best)? I'd hesitate to try to check for the presence of one or more labels as the admin could have intentionally removed them or changed them of course.

--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake

EDB: http://www.enterprisedb.com