Thanks Dominick!
I had already tried to add the role access from unconfined_r to
xguest_r with no luck, but I tried it right now and it simply worked!
module dominick 1.0;
require {
type unconfined_t;
type xguest_t;
class process transition;
role xguest_r;
role unconfined_r;
}
allow unconfined_t xguest_t:process transition;
allow unconfined_r xguest_r;
It works! Thanks again!
On Fri, Jan 29, 2010 at 8:49 PM, Dominick Grift <domg472@xxxxxxxxx> wrote:
> On 01/29/2010 08:53 PM, Fernando Magro wrote:
>> Hi there,
>>
>> I have fedora 11 installed and I'm running a program with root, but
>> need to drop priviledges to another user (xguest_u) and change to the
>> proper security context. When I tried to use simple tools like runcon
>> or newrole, I wasn't able to modify the context. I tried:
>>
>> su -c 'runcon -c -t xguest_t -u xguest_u -r xguest_r -l s0
>> /usr/bin/id' unpriviledged-user-that-is-xguest_u
>>
>> I always get permission denied. After checking /var/log/audit and
>> doing an audit2allow it pointed out:
>>
>> allow unconfined_t xguest_t : process transition.
>>
>> However, when I load the module, the problem continues... Any easy way
>> to run a program with another UID and another security context from
>> root/unconfined_t/unconfined_r?
>
> I guess policycoreutils sandbox could be useful here. Or create a user
> application domain policy.
>
> With regard to what you are trying there are a few things you could try:
>
> 1. leave out the -u xguest_u. This could cause issues i believe. ( I
> have had some weird issues in this regard which to me looked like ubac
> side effects on a configuration with ubac disabled but i may be wrong )
> 2. you probably need a rule allowing role access for unconfined_r: allow
> unconfined_r xguest_r; (looks for an SELINUX_ERR in audit.log)
> 3. You should probably also modify your unconfined_u selinux user
> mapping to include the xguest_r role.
>
> Unconfined user is not designed to transition to other user domains or
> roles (except probably system_r).
>
> I think it is probably best to create a user application domain. This
> allows you to define policy that is tailor made to your applications
> properties.
>
> You could probably also extend or clone a policycoreutils sandbox to
> meet the requirement of your application.
>>
>> thanks!
>> --
>> selinux mailing list
>> selinux@xxxxxxxxxxxxxxxxxxxxxxx
>> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
>
>
> --
> selinux mailing list
> selinux@xxxxxxxxxxxxxxxxxxxxxxx
> https://admin.fedoraproject.org/mailman/listinfo/selinux
>
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
