[v9.2] Add GUC sepgsql.client_label

On Tue, Jan 10, 2012 at 6:28 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

This patch adds a new GUC "sepgsql.client_label" that allows client
process to switch its privileges into another one, as long as the
system security policy admits this transition.
Because of this feature, I ported two permissions from "process" class
of SELinux; "setcurrent" and "dyntransition". The first one checks
whether the client has a right to switch its privilege. And the other
one checks a particular transition path from X to Y.

This feature might seem to break assumption of the sepgsql's security
model. However, single-directed domain transition from
bigger-privileges to smaller-privileged domain by users' operation is
also supported on operating system, and useful feature to restrict
applications capability at beginning of the session.

A few weeks ago, I got a requirement from Joshua Brindle. He is
working for Web-application that uses CAC (Common Access Card) for its
authentication, and wanted to integrate its security credential and
security label of selinux/sepgsql.
One problem was the system environment unavailable to use
labeled-networking (IPsec), thus, it was not an option to switch the
security label of processes on web-server side. An other solution is
to port dynamic-transition feature into sepgsql, as an analogy of
operating system.

An expected scenario is below:
The web-server is running with WEBSERV domain. It is allowed to
connect to PostgreSQL, and also allowed to invoke an trusted-procedure
that takes an argument of security-credential within CAC, but, nothing
else are allowed.
The trusted-procedure is allowed to reference a table between
security-credential and security-label to be assigned on, then it
switches the security label of client into CLIENT_n.
The CLIENT_n shall be allowed to access tables, functions and others
according to the security policy, and also allowed to reset
"sepgsql.security_label" to revert WEBSERV. However, he is not
available to switch other domain without security-credential stored
within CAC card.

I and Joshua agreed this scenario is reasonable and secure.
So, we'd like to suggest this new feature towards v9.2 timeline.

I'm wondering if a function would be a better fit than a GUC. I don't
think you can really restrict the ability to revert a GUC change -
i.e. if someone does a SET and then a RESET, you pretty much have to
allow that. I think. But if you expose a function then it can work
however you like.

On another note, this is an awfully large patch. Is there a separate
patch here that just does code rearrangement that should be separated
out?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

2012/1/26 Robert Haas <robertmhaas@gmail.com>:

I'm wondering if a function would be a better fit than a GUC.  I don't
think you can really restrict the ability to revert a GUC change -
i.e. if someone does a SET and then a RESET, you pretty much have to
allow that.  I think.  But if you expose a function then it can work
however you like.

One benefit to use GUC is that we can utilize existing mechanism to
revert a value set within a transaction block on error.
If we implement same functionality with functions, XactCallback allows
sepgsql to get control on appropriate timing?

On another note, this is an awfully large patch.  Is there a separate
patch here that just does code rearrangement that should be separated
out?

OK. I moved some routines related to client_label into label.c.
I'll separate this part from the new functionality part.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2012/1/26 Robert Haas <robertmhaas@gmail.com>:

I'm wondering if a function would be a better fit than a GUC.  I don't
think you can really restrict the ability to revert a GUC change -
i.e. if someone does a SET and then a RESET, you pretty much have to
allow that.  I think.  But if you expose a function then it can work
however you like.

One benefit to use GUC is that we can utilize existing mechanism to
revert a value set within a transaction block on error.
If we implement same functionality with functions, XactCallback allows
sepgsql to get control on appropriate timing?

Not sure, but I thought the use case was to set this at connection
startup time and then hand the connection off to a client. What keeps
the client from just issuing RESET?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

2012/1/26 Robert Haas <robertmhaas@gmail.com>:

On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2012/1/26 Robert Haas <robertmhaas@gmail.com>:

I'm wondering if a function would be a better fit than a GUC.  I don't
think you can really restrict the ability to revert a GUC change -
i.e. if someone does a SET and then a RESET, you pretty much have to
allow that.  I think.  But if you expose a function then it can work
however you like.

One benefit to use GUC is that we can utilize existing mechanism to
revert a value set within a transaction block on error.
If we implement same functionality with functions, XactCallback allows
sepgsql to get control on appropriate timing?

Not sure, but I thought the use case was to set this at connection
startup time and then hand the connection off to a client.  What keeps
the client from just issuing RESET?

In the use case of Joshua, the original security label does not privileges
to reference any tables, and it cannot translate any domains without
credential within IC-cards. Thus, RESET is harmless.

However, I also assume one other possible use-case; the originator
has privileges to translate 10 of different domains, but disallows to
revert it. In this case, RESET without permission checks are harmful.
(This scenario will be suitable with multi-category-model.)

Apart from this issue, I found a problem on implementation using GUC
options. It makes backend crash, if it tries to reset sepgsql.client_label
without permissions within error handler because of double-errors.

So, I'll try to modify the patch with an idea to use a function.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

2012/1/28 Kohei KaiGai <kaigai@kaigai.gr.jp>:

2012/1/26 Robert Haas <robertmhaas@gmail.com>:

On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2012/1/26 Robert Haas <robertmhaas@gmail.com>:

I'm wondering if a function would be a better fit than a GUC.  I don't
think you can really restrict the ability to revert a GUC change -
i.e. if someone does a SET and then a RESET, you pretty much have to
allow that.  I think.  But if you expose a function then it can work
however you like.

One benefit to use GUC is that we can utilize existing mechanism to
revert a value set within a transaction block on error.
If we implement same functionality with functions, XactCallback allows
sepgsql to get control on appropriate timing?

Not sure, but I thought the use case was to set this at connection
startup time and then hand the connection off to a client.  What keeps
the client from just issuing RESET?

In the use case of Joshua, the original security label does not privileges
to reference any tables, and it cannot translate any domains without
credential within IC-cards. Thus, RESET is harmless.

However, I also assume one other possible use-case; the originator
has privileges to translate 10 of different domains, but disallows to
revert it. In this case, RESET without permission checks are harmful.
(This scenario will be suitable with multi-category-model.)

Apart from this issue, I found a problem on implementation using GUC
options. It makes backend crash, if it tries to reset sepgsql.client_label
without permissions within error handler because of double-errors.

I found an idea to avoid this scenario.

The problematic case is reset GUC variable because of transaction
rollback and permission violation, however, we don't intend to apply
permission checks, since it is not committed yet.
Thus, I considered to check state of the transaction using
IsTransactionState() on the assign_hook of GUC variable.

Unlike function based implementation, it is available to utilize existing
infrastructure to set the client_label to be transaction-aware.

It shall be implemented as:

void
sepgsql_assign_client_label(const char *newval, void *extra)
{
if (!IsTransactionState)
return;

/* check whether valid security context */

/* check permission check to switch current context */
}

How about such an implementation?

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

On Sun, Jan 29, 2012 at 7:27 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2012/1/28 Kohei KaiGai <kaigai@kaigai.gr.jp>:

2012/1/26 Robert Haas <robertmhaas@gmail.com>:

On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2012/1/26 Robert Haas <robertmhaas@gmail.com>:

I'm wondering if a function would be a better fit than a GUC.  I don't
think you can really restrict the ability to revert a GUC change -
i.e. if someone does a SET and then a RESET, you pretty much have to
allow that.  I think.  But if you expose a function then it can work
however you like.

One benefit to use GUC is that we can utilize existing mechanism to
revert a value set within a transaction block on error.
If we implement same functionality with functions, XactCallback allows
sepgsql to get control on appropriate timing?

Not sure, but I thought the use case was to set this at connection
startup time and then hand the connection off to a client.  What keeps
the client from just issuing RESET?

In the use case of Joshua, the original security label does not privileges
to reference any tables, and it cannot translate any domains without
credential within IC-cards. Thus, RESET is harmless.

However, I also assume one other possible use-case; the originator
has privileges to translate 10 of different domains, but disallows to
revert it. In this case, RESET without permission checks are harmful.
(This scenario will be suitable with multi-category-model.)

Apart from this issue, I found a problem on implementation using GUC
options. It makes backend crash, if it tries to reset sepgsql.client_label
without permissions within error handler because of double-errors.

I found an idea to avoid this scenario.

The problematic case is reset GUC variable because of transaction
rollback and permission violation, however, we don't intend to apply
permission checks, since it is not committed yet.
Thus, I considered to check state of the transaction using
IsTransactionState() on the assign_hook of GUC variable.

Unlike function based implementation, it is available to utilize existing
infrastructure to set the client_label to be transaction-aware.

It shall be implemented as:

void
sepgsql_assign_client_label(const char *newval, void *extra)
{
   if (!IsTransactionState)
       return;

   /* check whether valid security context */

   /* check permission check to switch current context */
}

How about such an implementation?

Well, I think the idea that GUC changes can be reverted at any time is
fairly deeply ingrained in the GUC machinery. So I think that's a
hack: it might happen to work today (or at least on the cases we can
think of to test), but I wouldn't be a bit surprised if there are
other cases where it fails, either now or in the future. I don't see
any good reason to assume that unrevertable changes are OK even inside
a transaction context. For example, if someone applies a context to a
function with ALTER FUNCTION, they're going to expect that the altered
context remains in effect while the function is running and gets
reverted on exit. If you throw an error when the system tries to
revert the change at function-exit time, it might not crash the
server, but it's certainly going to violate the principle of least
astonishment.

Of course, we already have a trusted procedure mechanism which is
intended to support temporary changes to the effective security label,
so you might say, hey, people shouldn't do that. But they might. And
I wouldn't like to bet that's the only case that could be problematic
either. What about a setting in postgresql.conf? You could end up
being asked to set the security label to some other value before
you've initialized it. What about SET LOCAL? It's not OK to fail to
revert that at transaction exit.

Hence my suggestion of a function: if you use functions, you can
implement whatever semantics you want.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2012-01-30 19:19, Robert Haas wrote:

On Sun, Jan 29, 2012 at 7:27 AM, Kohei KaiGai<kaigai@kaigai.gr.jp> wrote:

However, I also assume one other possible use-case; the originator
has privileges to translate 10 of different domains, but disallows to
revert it. In this case, RESET without permission checks are harmful.
(This scenario will be suitable with multi-category-model.)

Of course, we already have a trusted procedure mechanism which is
intended to support temporary changes to the effective security label,
so you might say, hey, people shouldn't do that. But they might. And I
wouldn't like to bet that's the only case that could be problematic
either. What about a setting in postgresql.conf? You could end up
being asked to set the security label to some other value before
you've initialized it. What about SET LOCAL? It's not OK to fail to
revert that at transaction exit. Hence my suggestion of a function: if
you use functions, you can implement whatever semantics you want.

What about always allowing a transition to the default / postgresql.conf
configured client label, so in the case of errors, or RESET, the
transition to this domain is hardcoded to succeed. This would also be
useful in conjunction with a connection pooler. This would still allow
the option to prevent a back transition to non-default client labels.

--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data

On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havinga <yebhavinga@gmail.com> wrote:

What about always allowing a transition to the default / postgresql.conf
configured client label, so in the case of errors, or RESET, the transition
to this domain is hardcoded to succeed. This would also be useful in
conjunction with a connection pooler. This would still allow the option to
prevent a back transition to non-default client labels.

I don't think you can make that work, because someone can still
attempt to RESET to a different value, and it's still not safe to make
that fail.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2012-01-31 14:06, Robert Haas wrote:

On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havinga<yebhavinga@gmail.com> wrote:

What about always allowing a transition to the default / postgresql.conf
configured client label, so in the case of errors, or RESET, the transition
to this domain is hardcoded to succeed. This would also be useful in
conjunction with a connection pooler. This would still allow the option to
prevent a back transition to non-default client labels.

I don't think you can make that work, because someone can still
attempt to RESET to a different value, and it's still not safe to make
that fail.

But the idea is that if that different value is a (possibly changed into
a new) allowed default value, a RESET to that new default value will be
allowed, by definition, because it is a default value.

--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data

On Tue, Jan 31, 2012 at 9:10 AM, Yeb Havinga <yebhavinga@gmail.com> wrote:

On 2012-01-31 14:06, Robert Haas wrote:

On Tue, Jan 31, 2012 at 4:36 AM, Yeb Havinga<yebhavinga@gmail.com>  wrote:

What about always allowing a transition to the default / postgresql.conf
configured client label, so in the case of errors, or RESET, the
transition
to this domain is hardcoded to succeed. This would also be useful in
conjunction with a connection pooler. This would still allow the option
to
prevent a back transition to non-default client labels.

I don't think you can make that work, because someone can still
attempt to RESET to a different value, and it's still not safe to make
that fail.

But the idea is that if that different value is a (possibly changed into a
new) allowed default value, a RESET to that new default value will be
allowed, by definition, because it is a default value.

*scratches head*

I'm not sure I follow you. If you're saying that we can make this
work by always allowing the value to be reset, then I agree with you,
but I'm not sure those are the semantics KaiGai wants. For instance,
if a connection pooler does:

SET sepgsql.client_label = 'bob_t';

...and then hands off to the client, the client can then do:

RESET sepgsql.client_label;
SET sepgsql.client_label = 'alice_t';

....and that's bad. More generally, the system security policy is
designed to answer questions about whether it's OK to transition from
A->B, and the fact that A->B is OK does not mean that B->A is OK, but
our GUC mechanism pretty much forces you to allow both of those
things, or neither.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2012-01-31 15:28, Robert Haas wrote:

*scratches head*

I'm not sure I follow you. If you're saying that we can make this
work by always allowing the value to be reset, then I agree with you,
but I'm not sure those are the semantics KaiGai wants. For instance,
if a connection pooler does:

SET sepgsql.client_label = 'bob_t';

...and then hands off to the client, the client can then do:

RESET sepgsql.client_label;
SET sepgsql.client_label = 'alice_t';

....and that's bad.

Hmm yes this is a problem. Reading the original post better, it is also
not the intended behaviour to support repeatable client_label switches.

"However, single-directed domain transition from bigger-privileges to
smaller-privileged domain by users' operation is also supported on
operating system, and useful feature to restrict applications capability
at beginning of the session."

--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data

Robert Haas <robertmhaas@gmail.com> writes:

....and that's bad. More generally, the system security policy is
designed to answer questions about whether it's OK to transition from
A->B, and the fact that A->B is OK does not mean that B->A is OK, but
our GUC mechanism pretty much forces you to allow both of those
things, or neither.

More to the point, a GUC rollback transition *has to always succeed*.
Period. Now, the value that it's trying to roll back to was presumably
considered legitimate at some previous time, but if you're designing a
system that is based purely on state transitions it could very well see
the rollback transition as invalid. That is just going to be too
fragile to be acceptable.

I think that this will have to be set up so that it understands the
difference between a forward transition and a rollback and only checks
the former. If that's not possible, this is not going to get in.

regards, tom lane

Tom Lane wrote:

More to the point, a GUC rollback transition *has to always
succeed*. Period.

I was about to point out the exception of the transaction_read_only
GUC, which according to the standard must not be changed except at
the beginning of a transaction or a subtransaction, and must not be
changed from "on" to "off" in a subtransaction. Then I noticed that,
while we protect against an explicit change in a prohibited way, we
allow a RESET:

test=# begin transaction read only;
BEGIN
test=# select * from x;
x
---
1
(1 row)

test=# set transaction_read_only = off;
ERROR: transaction read-write mode must be set before any query
test=# rollback;
ROLLBACK
test=# begin transaction read only;
BEGIN
test=# select * from x;
x
---
1
(1 row)

test=# reset transaction_read_only ;
RESET
test=# insert into x VALUES (2);
INSERT 0 1
test=# commit;
COMMIT

I think that's a problem. It could allow back-door violations of
invariants enforced by triggers, and seems to violate the SQL
standard. I think this should be considered a bug, although I'm not
sure whether it's safe to back-patch, given the change to existing
behavior.

Whether such a (required) exception to what you assert above should
open the door to any others is another question.

-Kevin

"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:

Tom Lane wrote:

More to the point, a GUC rollback transition *has to always
succeed*. Period.

[ counterexample showing we should sometimes disallow "RESET" ]

This actually isn't what I was talking about: a RESET statement is a
commanded adoption of a new value that happens to be gotten off the
stack, and there's not a lot of logical difficulty in letting it fail.
What I was concerned about was the case where GUC is trying to
re-establish an old value during transaction rollback. For example,
assume we are superuser to start with, and we do

begin;
set role unprivileged_user;
...
rollback;

The rollback needs to transition the role setting back to superuser.
A check based purely on allowed transitions would disallow that, since
it's not visibly different from the unprivileged_user trying to make
himself superuser. You have to take the context of the state change
into account.

And yeah, I agree it's a bug that you can do what Kevin's example shows.

regards, tom lane

Tom Lane wrote:

What I was concerned about was the case where GUC is trying to
re-establish an old value during transaction rollback. For example,
assume we are superuser to start with, and we do

begin;
set role unprivileged_user;
...
rollback;

The rollback needs to transition the role setting back to
superuser.

Sorry for missing the point. Yeah, I totally agree with that.

And yeah, I agree it's a bug that you can do what Kevin's example
shows.

I'll look at it and see if I can pull together a patch.

-Kevin

2012/1/30 Robert Haas <robertmhaas@gmail.com>:

On Sun, Jan 29, 2012 at 7:27 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2012/1/28 Kohei KaiGai <kaigai@kaigai.gr.jp>:

2012/1/26 Robert Haas <robertmhaas@gmail.com>:

On Thu, Jan 26, 2012 at 2:07 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

2012/1/26 Robert Haas <robertmhaas@gmail.com>:

I'm wondering if a function would be a better fit than a GUC.  I don't
think you can really restrict the ability to revert a GUC change -
i.e. if someone does a SET and then a RESET, you pretty much have to
allow that.  I think.  But if you expose a function then it can work
however you like.

One benefit to use GUC is that we can utilize existing mechanism to
revert a value set within a transaction block on error.
If we implement same functionality with functions, XactCallback allows
sepgsql to get control on appropriate timing?

Not sure, but I thought the use case was to set this at connection
startup time and then hand the connection off to a client.  What keeps
the client from just issuing RESET?

In the use case of Joshua, the original security label does not privileges
to reference any tables, and it cannot translate any domains without
credential within IC-cards. Thus, RESET is harmless.

However, I also assume one other possible use-case; the originator
has privileges to translate 10 of different domains, but disallows to
revert it. In this case, RESET without permission checks are harmful.
(This scenario will be suitable with multi-category-model.)

Apart from this issue, I found a problem on implementation using GUC
options. It makes backend crash, if it tries to reset sepgsql.client_label
without permissions within error handler because of double-errors.

I found an idea to avoid this scenario.

The problematic case is reset GUC variable because of transaction
rollback and permission violation, however, we don't intend to apply
permission checks, since it is not committed yet.
Thus, I considered to check state of the transaction using
IsTransactionState() on the assign_hook of GUC variable.

Unlike function based implementation, it is available to utilize existing
infrastructure to set the client_label to be transaction-aware.

It shall be implemented as:

void
sepgsql_assign_client_label(const char *newval, void *extra)
{
   if (!IsTransactionState)
       return;

   /* check whether valid security context */

   /* check permission check to switch current context */
}

How about such an implementation?

Well, I think the idea that GUC changes can be reverted at any time is
fairly deeply ingrained in the GUC machinery.  So I think that's a
hack: it might happen to work today (or at least on the cases we can
think of to test), but I wouldn't be a bit surprised if there are
other cases where it fails, either now or in the future.  I don't see
any good reason to assume that unrevertable changes are OK even inside
a transaction context.  For example, if someone applies a context to a
function with ALTER FUNCTION, they're going to expect that the altered
context remains in effect while the function is running and gets
reverted on exit.  If you throw an error when the system tries to
revert the change at function-exit time, it might not crash the
server, but it's certainly going to violate the principle of least
astonishment.

Of course, we already have a trusted procedure mechanism which is
intended to support temporary changes to the effective security label,
so you might say, hey, people shouldn't do that.  But they might.  And
I wouldn't like to bet that's the only case that could be problematic
either.  What about a setting in postgresql.conf?  You could end up
being asked to set the security label to some other value before
you've initialized it.  What about SET LOCAL?  It's not OK to fail to
revert that at transaction exit.

Hence my suggestion of a function: if you use functions, you can
implement whatever semantics you want.

I tried to implement it based on the function approach.

The new sepgsql_setcon(TEXT) enables to set and reset alternative
security label of the database client, unless it violates permission
checks.

The supplied alternative security label is once appended on the
client_label_pending list, then an active item shall be saved on
the transaction commit time. If sub-transaction is rollbacked to
a particular savepoint, items on the pending-list shall be removed
according to its sub-transaction-id.

It extends idea of client_label into three types; peer-label, setcon-label
and func-label. The first one is obtained via getpeercon(3) on
database logon time, and always not null. The second one is set
using the new sepgsql_setcon(), and the other one is set during
execution of trusted procedure.

Thus, the logic of sepgsql_get_client_label() were modified to handle
these three kind of client labels correctly.

The attached part-1 patch moves related routines from hooks.c to
label.c because of references to static variables.
The part-2 patch implements above mechanism.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>

On Sun, Feb 5, 2012 at 4:09 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:

The attached part-1 patch moves related routines from hooks.c to
label.c because of references to static variables.

I have committed this part. Seems like a better location for that code, anyhow.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On 2012-02-05 10:09, Kohei KaiGai wrote:

The attached part-1 patch moves related routines from hooks.c to
label.c because of references to static variables. The part-2 patch
implements above mechanism.

I took a short look at this patch but am stuck getting the regression
test to run properly.

First, patch 2 misses the file sepgsql.sql.in and therefore the creation
function command for sepgsql_setcon is missing.

When that was solved, ./test_psql failed on the message that the psql
file may not be of object type unconfined_t. Once it was changed to
bin_t, the result output for the domain transition gives differences on
this output (the other parts of label.sql were ok) :

--
-- Test for Dynamic Domain Transition
--
-- validation of transaction aware dynamic-transition
/usr/bin/runcon: /usr/local/pgsql/bin/psql: Permission denied
/usr/bin/runcon: /usr/local/pgsql/bin/psql: Permission denied
/usr/bin/runcon: /usr/local/pgsql/bin/psql: Permission denied

However when I connect to the regression database directly, I can
execute the first setcon command but get
regression=# SELECT
sepgsql_setcon('unconfined_u:unconfined_r:unconfined_t:s0:c0.c12');
ERROR: SELinux: security policy violation

logfile shows
LOG: SELinux: denied { dyntransition }
scontext=unconfined_u:unconfined_r:unconfined_t:s0
tcontext=unconfined_u:unconfined_r:unconfined_t:s0:c0.c12 tclass=process

So maybe this is because my start domain is not s0-s0:c0.c1023

However, when trying to run bash or psql in domain
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 I get permission
denied.

Distribution is FC15, sestatus
SELinux status: enabled
SELinuxfs mount: /selinux
Current mode: enforcing
Mode from config file: enforcing
Policy version: 24
Policy from config file: targeted

--
Yeb Havinga
http://www.mgrid.net/
Mastering Medical Data

2012/2/20 Yeb Havinga <yebhavinga@gmail.com>:

On 2012-02-05 10:09, Kohei KaiGai wrote:

The attached part-1 patch moves related routines from hooks.c to label.c
because of references to static variables. The part-2 patch implements above
mechanism.

I took a short look at this patch but am stuck getting the regression test
to run properly.

First, patch 2 misses the file sepgsql.sql.in and therefore the creation
function command for sepgsql_setcon is missing.

Thanks for your comments.

I added the definition of sepgsql_setcon function to sepgsql.sql.in file,
in addition to patch rebasing.

So maybe this is because my start domain is not s0-s0:c0.c1023

However, when trying to run bash or psql in domain
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 I get permission
denied.

Distribution is FC15, sestatus
SELinux status:                 enabled
SELinuxfs mount:                /selinux
Current mode:                   enforcing
Mode from config file:          enforcing
Policy version:                 24
Policy from config file:        targeted

The "default" security policy does not permit dynamic domain transition
even if unconfined domain, in contradiction to its name.
(IMO, it is fair enough design to avoid single point of failure like root user.)

The security policy of regression test contains a set of rules to reduce
categories assigned to unconfined domain.
So, could you try the following steps.
1. Build the latest policy
% make -f /usr/share/selinux/devel/Makefile -C contrib/sepgsql
2. Install the policy module
% sudo semodule -i contrib/sepgsql/sepgsql-regtest.pp
3. Turn on the sepgsql_regression_test_mode
% sudo setsebool -P sepgsql_regression_test_mode=1

I believe it allows to switch security label of the client, as long as we try to
reduce categories.

Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>