From: Dominick Grift <dominick.grift@gmail.com>
To: Dan Pou <danielp@sgi.com>
Cc: SELinux-NSA <SELinux@tycho.nsa.gov>
Subject: Re: Programmatic domain change to unprivileged role
Date: Wed, 21 Aug 2013 17:58:20 +0200 [thread overview]
Message-ID: <1377100700.25761.26.camel@d30> (raw)
In-Reply-To: <20130821140533.GM28332@localhost>
On Wed, 2013-08-21 at 09:05 -0500, Dan Pou wrote:
> > Some things ( but i am not sure ):
> >
> > The target role needs to be associated to the identity (probably already
> > done)
> > The target role needs to be associated to the target domain (probably
> > already done)
> > The source role needs to be allowed to manually change to the target
> > role (probably already done)
> >
> > The source domain needs various permissions to change identity, role,
> > and set mls range (policy constraints: mlsprocsetsl
> > can_change_process_identity can_change_process_role )
> > The target security level must be within range of the selinux identity
> > associated level, range)
> >
> > You probably need to specify the entrypoint to the target domain
> > You probably need to allow the actual transition permission from source
> > domain to target domain (allow my_daemon_t user_t:process transition)
>
> Wouldn't these settings be associated with AVC denials? I am running
> Permissive and have no denials showing up.
>
I am not sure but here is what i think:
The function uses the policy to see if theres a valid path to the target
context by querying the policy used for calculation
So if the policy does not define a path the function will fail/abort,
thus it wont try it because it already determined that it wouldnt work
anyways. So you wont see ant avc denials because it didnt even try it
> >
> > As far as i know, the function calculates if what you specified is valid
> > first
> >
> > I do not think you need a automatic role transition rule (it changes
> > manually instead i believe)
>
> I thought you still needed to specify a transition with setexeccon. Is
> this not true?
I am not sure, but again, i believe that no automatic role transition is
needed
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.
next prev parent reply other threads:[~2013-08-21 15:58 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-08-05 19:07 Programmatic domain change to unprivileged role Dan Pou
2013-08-06 20:15 ` Stephen Smalley
2013-08-06 20:37 ` Dan Pou
2013-08-07 12:28 ` Stephen Smalley
2013-08-07 12:41 ` Stephen Smalley
2013-08-08 19:58 ` Dan Pou
2013-08-09 9:59 ` Daniel J Walsh
2013-08-09 12:51 ` Stephen Smalley
2013-08-20 20:05 ` Dan Pou
2013-08-21 7:54 ` Dominick Grift
2013-08-21 14:05 ` Dan Pou
2013-08-21 15:58 ` Dominick Grift [this message]
2013-08-21 14:22 ` Stephen Smalley
2013-08-21 14:27 ` Stephen Smalley
2013-08-22 22:50 ` Dan Pou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1377100700.25761.26.camel@d30 \
--to=dominick.grift@gmail.com \
--cc=SELinux@tycho.nsa.gov \
--cc=danielp@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.