[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Justin Mattock]

I know this may seem stupid, but why is SELinux PAM transitioning me like this?

Sep 15 20:25:48 Linux-2 pam: gdm-password[957]: pam_selinux(gdm-password:session): Open Session
Sep 15 20:25:48 Linux-2 pam: gdm-password[957]: pam_selinux(gdm-password:session): Open Session
Sep 15 20:25:48 Linux-2 pam: gdm-password[957]: pam_selinux(gdm-password:session): Username= justin SELinux User = justin Level= s0
Sep 15 20:25:48 Linux-2 pam: gdm-password[957]: pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned
Sep 15 20:25:48 Linux-2 pam: gdm-password[957]: pam_selinux(gdm-password:session): set justin security context to justin:staff_r:insmod_t:s0
Sep 15 20:25:48 Linux-2 pam: gdm-password[957]: pam_selinux(gdm-password:session): Key Creation Context justin:staff_r:insmod_t:s0 Assigned
Sep 15 20:25:48 Linux-2 pam: gdm-password[957]: pam_selinux(gdm-password:session): set justin key creation context to justin:staff_r:insmod_t:s0
Sep 15 20:25:48 Linux-2 pam: gdm-password[957]: pam_unix(gdm-password:session): session opened for user justin by (uid=0)


I have had this in the past with other systems, but a relabel has always resolved this., now with using fedora 15 seems I have no idea! any ideas on what I may need to check? boolean?

Justin P. Mattock

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/15/2011 11:40 PM, Justin Mattock wrote:
> I know this may seem stupid, but why is SELinux PAM transitioning
> me like this?
> 
> Sep 15 20:25:48 Linux-2 pam: gdm-password[957]:
> pam_selinux(gdm-password:session): Open Session Sep 15 20:25:48
> Linux-2 pam: gdm-password[957]: pam_selinux(gdm-password:session):
> Open Session Sep 15 20:25:48 Linux-2 pam: gdm-password[957]:
> pam_selinux(gdm-password:session): Username= justin SELinux User =
> justin Level= s0 Sep 15 20:25:48 Linux-2 pam: gdm-password[957]:
> pam_selinux(gdm-password:session): Security Context
> justin:staff_r:insmod_t:s0 Assigned Sep 15 20:25:48 Linux-2 pam:
> gdm-password[957]: pam_selinux(gdm-password:session): set justin
> security context to justin:staff_r:insmod_t:s0 Sep 15 20:25:48
> Linux-2 pam: gdm-password[957]: pam_selinux(gdm-password:session):
> Key Creation Context justin:staff_r:insmod_t:s0 Assigned Sep 15
> 20:25:48 Linux-2 pam: gdm-password[957]:
> pam_selinux(gdm-password:session): set justin key creation context
> to justin:staff_r:insmod_t:s0 Sep 15 20:25:48 Linux-2 pam:
> gdm-password[957]: pam_unix(gdm-password:session): session opened
> for user justin by (uid=0)
> 
> 
> I have had this in the past with other systems, but a relabel has
> always resolved this., now with using fedora 15 seems I have no
> idea! any ideas on what I may need to check? boolean?
> 
> Justin P. Mattock
> 
> _______________________________________________ refpolicy mailing
> list refpolicy@oss.tresys.com 
> http://oss.tresys.com/mailman/listinfo/refpolicy
What is the context of the login program.

ps -eZ |grep sshd

For example.

The code asks what context to log in justin at based on its current
context.  If the login program has a bizare context like unconfined_t
or initrc_t the code can get confused.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5zZFMACgkQrlYvE4MpobNmCACfRirK7RP5I1rQPy193KZAapl9
droAoK8wKjd9xgB+p5QSmueukch3ZUha
=1iP6
-----END PGP SIGNATURE-----

--
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.

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/15/2011 11:40 PM, Justin Mattock wrote:
> I know this may seem stupid, but why is SELinux PAM transitioning
> me like this?
> 
> Sep 15 20:25:48 Linux-2 pam: gdm-password[957]:
> pam_selinux(gdm-password:session): Open Session Sep 15 20:25:48
> Linux-2 pam: gdm-password[957]: pam_selinux(gdm-password:session):
> Open Session Sep 15 20:25:48 Linux-2 pam: gdm-password[957]:
> pam_selinux(gdm-password:session): Username= justin SELinux User =
> justin Level= s0 Sep 15 20:25:48 Linux-2 pam: gdm-password[957]:
> pam_selinux(gdm-password:session): Security Context
> justin:staff_r:insmod_t:s0 Assigned Sep 15 20:25:48 Linux-2 pam:
> gdm-password[957]: pam_selinux(gdm-password:session): set justin
> security context to justin:staff_r:insmod_t:s0 Sep 15 20:25:48
> Linux-2 pam: gdm-password[957]: pam_selinux(gdm-password:session):
> Key Creation Context justin:staff_r:insmod_t:s0 Assigned Sep 15
> 20:25:48 Linux-2 pam: gdm-password[957]:
> pam_selinux(gdm-password:session): set justin key creation context
> to justin:staff_r:insmod_t:s0 Sep 15 20:25:48 Linux-2 pam:
> gdm-password[957]: pam_unix(gdm-password:session): session opened
> for user justin by (uid=0)
> 
> 
> I have had this in the past with other systems, but a relabel has
> always resolved this., now with using fedora 15 seems I have no
> idea! any ideas on what I may need to check? boolean?
> 
> Justin P. Mattock
> 
> _______________________________________________ refpolicy mailing
> list refpolicy at oss.tresys.com 
> http://oss.tresys.com/mailman/listinfo/refpolicy
What is the context of the login program.

ps -eZ |grep sshd

For example.

The code asks what context to log in justin at based on its current
context.  If the login program has a bizare context like unconfined_t
or initrc_t the code can get confused.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5zZFMACgkQrlYvE4MpobNmCACfRirK7RP5I1rQPy193KZAapl9
droAoK8wKjd9xgB+p5QSmueukch3ZUha
=1iP6
-----END PGP SIGNATURE-----

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Justin P. Mattock]

On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
> ps -eZ |grep sshd
I dont have sshd running, but here is ps auxZ to give you an idea of 
what I am seeing:
http://fpaste.org/u6IB/

if I adjust /etc/pam.d/login and add select_context to pam_selinux.so 
then do init 3 in lilo I am able to have the context
justin:staff_r:staff_t:s0  the way it should. but as soon as I init 5 
gdm starts up, and everything goes back to name:staff_r:insmod_t:s0

I think I am either missing a boolean to have the transisiton runing 
properly, and/or pam.d or some config file somewhere needs to be adjusted.
keep in mind refpolicy has no patches added to it(not sure if I need any 
for systemd), just plain git pull  etc...

Justin P. Mattock
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110916/904bf687/attachment.html 

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/16/2011 11:22 AM, Justin P. Mattock wrote:
> On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
>> ps -eZ |grep sshd
> I dont have sshd running, but here is ps auxZ to give you an idea
> of what I am seeing: http://fpaste.org/u6IB/
> 
> if I adjust /etc/pam.d/login and add select_context to
> pam_selinux.so then do init 3 in lilo I am able to have the
> context justin:staff_r:staff_t:s0  the way it should. but as soon
> as I init 5 gdm starts up, and everything goes back to
> name:staff_r:insmod_t:s0
> 
> I think I am either missing a boolean to have the transisiton
> runing properly, and/or pam.d or some config file somewhere needs
> to be adjusted. keep in mind refpolicy has no patches added to
> it(not sure if I need any for systemd), just plain git pull
> etc...
> 
> Justin P. Mattock
Well since you don't have a init_t running, I think your problem
starts there.  Looks like your system is badly mislabeled or something
in init is broken.   I take it this is not a Red Hat Based OS?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5zciMACgkQrlYvE4MpobOs4wCcD/KSvuhb5GxhPCZcMEDGI1dD
X70AnR2OLyUzsaLlDRmP0jm7ABwzFHBj
=aH02
-----END PGP SIGNATURE-----

--
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.

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/16/2011 11:22 AM, Justin P. Mattock wrote:
> On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
>> ps -eZ |grep sshd
> I dont have sshd running, but here is ps auxZ to give you an idea
> of what I am seeing: http://fpaste.org/u6IB/
> 
> if I adjust /etc/pam.d/login and add select_context to
> pam_selinux.so then do init 3 in lilo I am able to have the
> context justin:staff_r:staff_t:s0  the way it should. but as soon
> as I init 5 gdm starts up, and everything goes back to
> name:staff_r:insmod_t:s0
> 
> I think I am either missing a boolean to have the transisiton
> runing properly, and/or pam.d or some config file somewhere needs
> to be adjusted. keep in mind refpolicy has no patches added to
> it(not sure if I need any for systemd), just plain git pull
> etc...
> 
> Justin P. Mattock
Well since you don't have a init_t running, I think your problem
starts there.  Looks like your system is badly mislabeled or something
in init is broken.   I take it this is not a Red Hat Based OS?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk5zciMACgkQrlYvE4MpobOs4wCcD/KSvuhb5GxhPCZcMEDGI1dD
X70AnR2OLyUzsaLlDRmP0jm7ABwzFHBj
=aH02
-----END PGP SIGNATURE-----

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

On Fri, 2011-09-16 at 08:22 -0700, Justin P. Mattock wrote:
> On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
> > ps -eZ |grep sshd
> I dont have sshd running, but here is ps auxZ to give you an idea of 
> what I am seeing:
> http://fpaste.org/u6IB/

Graphical environment is not running in the proper context.

Not even init has transitioned properly to its own context.

> if I adjust /etc/pam.d/login and add select_context to pam_selinux.so 
> then do init 3 in lilo I am able to have the context
> justin:staff_r:staff_t:s0  the way it should. but as soon as I init 5 
> gdm starts up, and everything goes back to name:staff_r:insmod_t:s0
> 
> I think I am either missing a boolean to have the transisiton runing 

Why don't you post the booleans that you're using then:

getsebool -a

For example, what are you using for init ? If you're using upstart, have
you set init_upstart=on ?

> properly, and/or pam.d or some config file somewhere needs to be adjusted.
> keep in mind refpolicy has no patches added to it(not sure if I need any 
> for systemd), just plain git pull  etc...

So are you using systemd for init ? There is a boolean called
init_systemd which possibly is similar to the above mentioned one for
upstart.

Start from tackling init running in the kernel context and not
transitioning to init_t. The rest might be mostly due to that: personal
experience.

> Justin P. Mattock

Guido


--
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.

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

On Fri, 2011-09-16 at 08:22 -0700, Justin P. Mattock wrote:
> On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
> > ps -eZ |grep sshd
> I dont have sshd running, but here is ps auxZ to give you an idea of 
> what I am seeing:
> http://fpaste.org/u6IB/

Graphical environment is not running in the proper context.

Not even init has transitioned properly to its own context.

> if I adjust /etc/pam.d/login and add select_context to pam_selinux.so 
> then do init 3 in lilo I am able to have the context
> justin:staff_r:staff_t:s0  the way it should. but as soon as I init 5 
> gdm starts up, and everything goes back to name:staff_r:insmod_t:s0
> 
> I think I am either missing a boolean to have the transisiton runing 

Why don't you post the booleans that you're using then:

getsebool -a

For example, what are you using for init ? If you're using upstart, have
you set init_upstart=on ?

> properly, and/or pam.d or some config file somewhere needs to be adjusted.
> keep in mind refpolicy has no patches added to it(not sure if I need any 
> for systemd), just plain git pull  etc...

So are you using systemd for init ? There is a boolean called
init_systemd which possibly is similar to the above mentioned one for
upstart.

Start from tackling init running in the kernel context and not
transitioning to init_t. The rest might be mostly due to that: personal
experience.

> Justin P. Mattock

Guido

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

On Fri, 2011-09-16 at 11:58 -0400, Daniel J Walsh wrote:
> On 09/16/2011 11:22 AM, Justin P. Mattock wrote:
> > On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
> >> ps -eZ |grep sshd
> > I dont have sshd running, but here is ps auxZ to give you an idea
> > of what I am seeing: http://fpaste.org/u6IB/
> > 
> > if I adjust /etc/pam.d/login and add select_context to
> > pam_selinux.so then do init 3 in lilo I am able to have the
> > context justin:staff_r:staff_t:s0  the way it should. but as soon
> > as I init 5 gdm starts up, and everything goes back to
> > name:staff_r:insmod_t:s0
> > 
> > I think I am either missing a boolean to have the transisiton
> > runing properly, and/or pam.d or some config file somewhere needs
> > to be adjusted. keep in mind refpolicy has no patches added to
> > it(not sure if I need any for systemd), just plain git pull
> > etc...
> > 
> > Justin P. Mattock
> Well since you don't have a init_t running, I think your problem
> starts there.  Looks like your system is badly mislabeled or something
> in init is broken.   I take it this is not a Red Hat Based OS?

Also please post the actual label of the init executable:

ls -lZ /sbin/init

or wherever that is.

It should be init_exec_t.

Init is the father of all processes, if it hasn't transitioned properly
to init_t soon after booting up, then it all goes tits up...

- check the label above;
- try relabeling the whole filesystem;
- try the init_systemd boolean if you are using systemd as init.

Please keep up informed on the progress.

Guido


--
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.

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

On Fri, 2011-09-16 at 11:58 -0400, Daniel J Walsh wrote:
> On 09/16/2011 11:22 AM, Justin P. Mattock wrote:
> > On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
> >> ps -eZ |grep sshd
> > I dont have sshd running, but here is ps auxZ to give you an idea
> > of what I am seeing: http://fpaste.org/u6IB/
> > 
> > if I adjust /etc/pam.d/login and add select_context to
> > pam_selinux.so then do init 3 in lilo I am able to have the
> > context justin:staff_r:staff_t:s0  the way it should. but as soon
> > as I init 5 gdm starts up, and everything goes back to
> > name:staff_r:insmod_t:s0
> > 
> > I think I am either missing a boolean to have the transisiton
> > runing properly, and/or pam.d or some config file somewhere needs
> > to be adjusted. keep in mind refpolicy has no patches added to
> > it(not sure if I need any for systemd), just plain git pull
> > etc...
> > 
> > Justin P. Mattock
> Well since you don't have a init_t running, I think your problem
> starts there.  Looks like your system is badly mislabeled or something
> in init is broken.   I take it this is not a Red Hat Based OS?

Also please post the actual label of the init executable:

ls -lZ /sbin/init

or wherever that is.

It should be init_exec_t.

Init is the father of all processes, if it hasn't transitioned properly
to init_t soon after booting up, then it all goes tits up...

- check the label above;
- try relabeling the whole filesystem;
- try the init_systemd boolean if you are using systemd as init.

Please keep up informed on the progress.

Guido

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Justin P. Mattock]

On 09/16/2011 08:58 AM, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 09/16/2011 11:22 AM, Justin P. Mattock wrote:
>> On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
>>> ps -eZ |grep sshd
>> I dont have sshd running, but here is ps auxZ to give you an idea
>> of what I am seeing: http://fpaste.org/u6IB/
>>
>> if I adjust /etc/pam.d/login and add select_context to
>> pam_selinux.so then do init 3 in lilo I am able to have the
>> context justin:staff_r:staff_t:s0  the way it should. but as soon
>> as I init 5 gdm starts up, and everything goes back to
>> name:staff_r:insmod_t:s0
>>
>> I think I am either missing a boolean to have the transisiton
>> runing properly, and/or pam.d or some config file somewhere needs
>> to be adjusted. keep in mind refpolicy has no patches added to
>> it(not sure if I need any for systemd), just plain git pull
>> etc...
>>
>> Justin P. Mattock
> Well since you don't have a init_t running, I think your problem
> starts there.  Looks like your system is badly mislabeled or something
> in init is broken.   I take it this is not a Red Hat Based OS?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk5zciMACgkQrlYvE4MpobOs4wCcD/KSvuhb5GxhPCZcMEDGI1dD
> X70AnR2OLyUzsaLlDRmP0jm7ABwzFHBj
> =aH02
> -----END PGP SIGNATURE-----
the system is fedora 15 nothing tweaked on it. just refpolicy from git 
targeted form fedora works fine,
just thought I would give refpolicy-git a try.

think I need to read up on systemd
ls -Z /lib/systemd looks like this:
http://fpaste.org/WOFw/

wondering if maybe /etc/security/pam_env.conf is capable of putting me 
into the right context, but then again if
this is just a label issue, then pam_env.conf is not touched.

Justin P. Mattock




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110916/38c817a7/attachment-0001.html 

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Justin P. Mattock]

On 09/16/2011 09:02 AM, Guido Trentalancia wrote:
> getsebool -a
at the bottom of the fpaste
as for init
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/init -> 
../bin/systemd

looks like somewhere somehow the label was labeled wrong.
stange, I loaded refpolicy(mcs) from fedora's targeted then did sudo 
make relabel from refpolicy even fixfiles relabel at another point in 
time. there is no patch needed for systemd? that needs to be added to 
refpolicy-git?

Justin P. Mattock
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110916/806b4408/attachment.html 

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Justin P. Mattock]

On 09/16/2011 09:02 AM, Guido Trentalancia wrote:
> On Fri, 2011-09-16 at 08:22 -0700, Justin P. Mattock wrote:
>> On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
>>> ps -eZ |grep sshd
>> I dont have sshd running, but here is ps auxZ to give you an idea of
>> what I am seeing:
>> http://fpaste.org/u6IB/
> Graphical environment is not running in the proper context.
>
> Not even init has transitioned properly to its own context.
>
>> if I adjust /etc/pam.d/login and add select_context to pam_selinux.so
>> then do init 3 in lilo I am able to have the context
>> justin:staff_r:staff_t:s0  the way it should. but as soon as I init 5
>> gdm starts up, and everything goes back to name:staff_r:insmod_t:s0
>>
>> I think I am either missing a boolean to have the transisiton runing
> Why don't you post the booleans that you're using then:
>
> getsebool -a
>
> For example, what are you using for init ? If you're using upstart, have
> you set init_upstart=on ?
>
>> properly, and/or pam.d or some config file somewhere needs to be adjusted.
>> keep in mind refpolicy has no patches added to it(not sure if I need any
>> for systemd), just plain git pull  etc...
> So are you using systemd for init ? There is a boolean called
> init_systemd which possibly is similar to the above mentioned one for
> upstart.
>
> Start from tackling init running in the kernel context and not
> transitioning to init_t. The rest might be mostly due to that: personal
> experience.
>
>> Justin P. Mattock
> Guido
>

looking more into fedora(s) structure of what they have:
/sbin/init -> ../bin/systemd

  ls -lZ /sbin/init
lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/init -> 
../bin/systemd
[justin at Linux-2 ~]$ ls -lZ /bin/systemd
-rwxr-xr-x. root root system_u:object_r:init_exec_t:s0 /bin/systemd

using chcon on:
chcon system_u:object_r:init_exec_t:s0 /sbin/init
seems to not change this for whatever the reason. keep in mind I am not 
sure how systemd runs or is setup.

Justin P. Mattock


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110916/705b9953/attachment.html 

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

On Fri, 2011-09-16 at 09:18 -0700, Justin P. Mattock wrote:
> On 09/16/2011 09:02 AM, Guido Trentalancia wrote: 
> > getsebool -a
> at the bottom of the fpaste 
> as for init
> lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/init
> -> ../bin/systemd

That's the label of the link. Need the label of the target:

ls -lZ /bin/systemd

or whatever that is.

> looks like somewhere somehow the label was labeled wrong.
> stange, I loaded refpolicy(mcs) from fedora's targeted then did sudo
> make relabel from refpolicy even fixfiles relabel at another point in
> time. there is no patch needed for systemd? that needs to be added to
> refpolicy-git?

Moving from Fedora targeted to refpolicy mcs is not just exactly a very
straight thing. As far as I remember when I first installed refpolicy I
hit the init_upstart boolean issue. That's why I recommend you look up
your init_systemd boolean:

setsebool init_systemd=on

> Justin P. Mattock

Guido


--
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.

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

On Fri, 2011-09-16 at 09:18 -0700, Justin P. Mattock wrote:
> On 09/16/2011 09:02 AM, Guido Trentalancia wrote: 
> > getsebool -a
> at the bottom of the fpaste 
> as for init
> lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/init
> -> ../bin/systemd

That's the label of the link. Need the label of the target:

ls -lZ /bin/systemd

or whatever that is.

> looks like somewhere somehow the label was labeled wrong.
> stange, I loaded refpolicy(mcs) from fedora's targeted then did sudo
> make relabel from refpolicy even fixfiles relabel at another point in
> time. there is no patch needed for systemd? that needs to be added to
> refpolicy-git?

Moving from Fedora targeted to refpolicy mcs is not just exactly a very
straight thing. As far as I remember when I first installed refpolicy I
hit the init_upstart boolean issue. That's why I recommend you look up
your init_systemd boolean:

setsebool init_systemd=on

> Justin P. Mattock

Guido

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

On Fri, 2011-09-16 at 09:24 -0700, Justin P. Mattock wrote:
> On 09/16/2011 09:02 AM, Guido Trentalancia wrote: 
> > On Fri, 2011-09-16 at 08:22 -0700, Justin P. Mattock wrote:
> > > On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
> > > > ps -eZ |grep sshd
> > > I dont have sshd running, but here is ps auxZ to give you an idea of 
> > > what I am seeing:
> > > http://fpaste.org/u6IB/
> > Graphical environment is not running in the proper context.
> > 
> > Not even init has transitioned properly to its own context.
> > 
> > > if I adjust /etc/pam.d/login and add select_context to pam_selinux.so 
> > > then do init 3 in lilo I am able to have the context
> > > justin:staff_r:staff_t:s0  the way it should. but as soon as I init 5 
> > > gdm starts up, and everything goes back to name:staff_r:insmod_t:s0
> > > 
> > > I think I am either missing a boolean to have the transisiton runing 
> > Why don't you post the booleans that you're using then:
> > 
> > getsebool -a
> > 
> > For example, what are you using for init ? If you're using upstart, have
> > you set init_upstart=on ?
> > 
> > > properly, and/or pam.d or some config file somewhere needs to be adjusted.
> > > keep in mind refpolicy has no patches added to it(not sure if I need any 
> > > for systemd), just plain git pull  etc...
> > So are you using systemd for init ? There is a boolean called
> > init_systemd which possibly is similar to the above mentioned one for
> > upstart.
> > 
> > Start from tackling init running in the kernel context and not
> > transitioning to init_t. The rest might be mostly due to that: personal
> > experience.
> > 
> > > Justin P. Mattock
> > Guido
> > 
> 
> looking more into fedora(s) structure of what they have:
> /sbin/init -> ../bin/systemd
> 
>  ls -lZ /sbin/init
> lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/init
> -> ../bin/systemd
> [justin at Linux-2 ~]$ ls -lZ /bin/systemd
> -rwxr-xr-x. root root system_u:object_r:init_exec_t:s0 /bin/systemd

Excellent.

> using chcon on:
> chcon system_u:object_r:init_exec_t:s0 /sbin/init
> seems to not change this for whatever the reason.

That's just the link, don't worry about that. The important is the label
on the target.

>  keep in mind I am not sure how systemd runs or is setup.

Now move onto the next enabler:

setsebool -P init_systemd=on

In my previous message I did forget the "-P" option, that's vital.

> Justin P. Mattock

Guido

[refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Justin P. Mattock]

On 09/16/2011 09:27 AM, Guido Trentalancia wrote:
> On Fri, 2011-09-16 at 09:18 -0700, Justin P. Mattock wrote:
>> On 09/16/2011 09:02 AM, Guido Trentalancia wrote:
>>> getsebool -a
>> at the bottom of the fpaste
>> as for init
>> lrwxrwxrwx. root root system_u:object_r:bin_t:s0       /sbin/init
>> ->  ../bin/systemd
> That's the label of the link. Need the label of the target:
>
> ls -lZ /bin/systemd
>
> or whatever that is.

then systemd is labelled correctly:
ls -lZ /bin/systemd
-rwxr-xr-x. root root system_u:object_r:init_exec_t:s0 /bin/systemd

as for a boolean, the only one I can see _remotely_ close to init_systemd=on
is init_upstart --> on in of which is set to on.

>
>> looks like somewhere somehow the label was labeled wrong.
>> stange, I loaded refpolicy(mcs) from fedora's targeted then did sudo
>> make relabel from refpolicy even fixfiles relabel at another point in
>> time. there is no patch needed for systemd? that needs to be added to
>> refpolicy-git?
> Moving from Fedora targeted to refpolicy mcs is not just exactly a very
> straight thing. As far as I remember when I first installed refpolicy I
> hit the init_upstart boolean issue. That's why I recommend you look up
> your init_systemd boolean:
>
> setsebool init_systemd=on
>
>> Justin P. Mattock
> Guido
>
Justin P. Mattock
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110916/85e3f59e/attachment.html 

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

On Fri, 2011-09-16 at 11:58 -0400, Daniel J Walsh wrote:
> On 09/16/2011 11:22 AM, Justin P. Mattock wrote:
> > On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
> >> ps -eZ |grep sshd
> > I dont have sshd running, but here is ps auxZ to give you an idea
> > of what I am seeing: http://fpaste.org/u6IB/
> > 
> > if I adjust /etc/pam.d/login and add select_context to
> > pam_selinux.so then do init 3 in lilo I am able to have the
> > context justin:staff_r:staff_t:s0  the way it should. but as soon
> > as I init 5 gdm starts up, and everything goes back to
> > name:staff_r:insmod_t:s0
> > 
> > I think I am either missing a boolean to have the transisiton
> > runing properly, and/or pam.d or some config file somewhere needs
> > to be adjusted. keep in mind refpolicy has no patches added to
> > it(not sure if I need any for systemd), just plain git pull
> > etc...
> > 
> > Justin P. Mattock
> Well since you don't have a init_t running, I think your problem
> starts there.  Looks like your system is badly mislabeled or something
> in init is broken.   I take it this is not a Red Hat Based OS?

I'd actually like to take this opportunity to stress once again that in
my opinion the system boot/init process should fail irreversibly as soon
as the init process has failed to transition to its own designated
context from the initial kernel context.

Regards,

Guido


--
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.

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/23/2011 12:30 PM, Guido Trentalancia wrote:
> On Fri, 2011-09-16 at 11:58 -0400, Daniel J Walsh wrote:
>> On 09/16/2011 11:22 AM, Justin P. Mattock wrote:
>>> On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
>>>> ps -eZ |grep sshd
>>> I dont have sshd running, but here is ps auxZ to give you an
>>> idea of what I am seeing: http://fpaste.org/u6IB/
>>> 
>>> if I adjust /etc/pam.d/login and add select_context to 
>>> pam_selinux.so then do init 3 in lilo I am able to have the 
>>> context justin:staff_r:staff_t:s0  the way it should. but as
>>> soon as I init 5 gdm starts up, and everything goes back to 
>>> name:staff_r:insmod_t:s0
>>> 
>>> I think I am either missing a boolean to have the transisiton 
>>> runing properly, and/or pam.d or some config file somewhere
>>> needs to be adjusted. keep in mind refpolicy has no patches
>>> added to it(not sure if I need any for systemd), just plain git
>>> pull etc...
>>> 
>>> Justin P. Mattock
>> Well since you don't have a init_t running, I think your problem 
>> starts there.  Looks like your system is badly mislabeled or
>> something in init is broken.   I take it this is not a Red Hat
>> Based OS?
> 
> I'd actually like to take this opportunity to stress once again
> that in my opinion the system boot/init process should fail
> irreversibly as soon as the init process has failed to transition
> to its own designated context from the initial kernel context.
> 
> Regards,
> 
> Guido
> 
> 
> -- 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.
> 
> 
Well it does crash if you are in enforcing mode on RHEL and Fedora boxes.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk58xB4ACgkQrlYvE4MpobOknQCgvZvYJt8MWanDw1B64Ch7pcfk
TXQAoLu6vU0y6Bk7wj8oTE4anrnArCXM
=ztXT
-----END PGP SIGNATURE-----

--
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.

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

On Fri, 2011-09-23 at 13:38 -0400, Daniel J Walsh wrote:
> On 09/23/2011 12:30 PM, Guido Trentalancia wrote:
> > On Fri, 2011-09-16 at 11:58 -0400, Daniel J Walsh wrote:
> >> On 09/16/2011 11:22 AM, Justin P. Mattock wrote:
> >>> On 09/16/2011 07:59 AM, Daniel J Walsh wrote:
> >>>> ps -eZ |grep sshd
> >>> I dont have sshd running, but here is ps auxZ to give you an
> >>> idea of what I am seeing: http://fpaste.org/u6IB/
> >>> 
> >>> if I adjust /etc/pam.d/login and add select_context to 
> >>> pam_selinux.so then do init 3 in lilo I am able to have the 
> >>> context justin:staff_r:staff_t:s0  the way it should. but as
> >>> soon as I init 5 gdm starts up, and everything goes back to 
> >>> name:staff_r:insmod_t:s0
> >>> 
> >>> I think I am either missing a boolean to have the transisiton 
> >>> runing properly, and/or pam.d or some config file somewhere
> >>> needs to be adjusted. keep in mind refpolicy has no patches
> >>> added to it(not sure if I need any for systemd), just plain git
> >>> pull etc...
> >>> 
> >>> Justin P. Mattock
> >> Well since you don't have a init_t running, I think your problem 
> >> starts there.  Looks like your system is badly mislabeled or
> >> something in init is broken.   I take it this is not a Red Hat
> >> Based OS?
> > 
> > I'd actually like to take this opportunity to stress once again
> > that in my opinion the system boot/init process should fail
> > irreversibly as soon as the init process has failed to transition
> > to its own designated context from the initial kernel context.
> > 
> > Regards,
> > 
> > Guido
> > 
> > 
> > -- 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.
> > 
> > 
> Well it does crash if you are in enforcing mode on RHEL and Fedora boxes.

Yes, very good. At the end, a very polite message is not the first
priority in such as situation...

But unfortunately this is not the case for the upstream bits.

Ideally should be tackled in the SELinux kernel code. Did RHEL and
Fedora patch the kernel then to achieve that ?

Regards,

Guido


--
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.

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Eric Paris]

On Fri, Sep 23, 2011 at 3:09 PM, Guido Trentalancia
<guido@trentalancia.com> wrote:
> On Fri, 2011-09-23 at 13:38 -0400, Daniel J Walsh wrote:

> Yes, very good. At the end, a very polite message is not the first
> priority in such as situation...
>
> But unfortunately this is not the case for the upstream bits.
>
> Ideally should be tackled in the SELinux kernel code. Did RHEL and
> Fedora patch the kernel then to achieve that ?

No we consider init to be part of the trusted base required to load
policy.  The Fedora init (systemd not, but it's been old init, some
scripts in the initramfs, and who know what else) tries to load policy
and if it can't and it was supposed to be enforcing will either print
and error and halt for a really long time and then exit, or exit
directly.  init exiting is enough to make the kernel panic and thus
shut down the box.

The tool that is trusted to load the policy is what needs to make this check.

-Eric

--
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.

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

On Fri, 2011-09-23 at 16:45 -0400, Eric Paris wrote:
> On Fri, Sep 23, 2011 at 3:09 PM, Guido Trentalancia
> <guido@trentalancia.com> wrote:
> > On Fri, 2011-09-23 at 13:38 -0400, Daniel J Walsh wrote:
> 
> > Yes, very good. At the end, a very polite message is not the first
> > priority in such as situation...
> >
> > But unfortunately this is not the case for the upstream bits.
> >
> > Ideally should be tackled in the SELinux kernel code. Did RHEL and
> > Fedora patch the kernel then to achieve that ?
> 
> No we consider init to be part of the trusted base required to load
> policy.  The Fedora init (systemd not, but it's been old init, some
> scripts in the initramfs, and who know what else) tries to load policy
> and if it can't and it was supposed to be enforcing will either print
> and error and halt for a really long time and then exit, or exit
> directly.  init exiting is enough to make the kernel panic and thus
> shut down the box.
> 
> The tool that is trusted to load the policy is what needs to make this check.

What really confuses me at this point is the fact that within this
specific thread, Justin said that he was using Fedora (F15 as far as I
remember).

Anyway, apart from the specific case, it remains the fact that the
upstream SELinux + reference policy combo does allow the system to keep
running (in the wrong context, i.e. kernel_t or insmod_t) despite init
has not transitioned to its context after initial stage. I am not
particularly keen on this behavior.

You seem to suggest that load_policy -i (and not the kernel) should make
sure that init has transitioned to its designated context... So then,
getting back to the specific case at hand, my question becomes: "did
Fedora and RHEL patch the upstream load_policy tool to achieve this
halt-on-init-failure behavior ?". In any case, how comes this check
didn't work on Justin's system ?

Regards,

Guido


--
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.

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Eric Paris]

On Fri, 2011-09-23 at 23:12 +0200, Guido Trentalancia wrote:

> You seem to suggest that load_policy -i (and not the kernel) should make
> sure that init has transitioned to its designated context...

Can't speak for Justin's system.  But that's not what I said.  I said
it's /sbin/init's problem to make sure it did the right thing and to
handle errors correctly if it failed.  If Justin has his box enforcing
and can boot without loading a policy that's a bug and needs to be
filed.

-Eric


--
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.

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

Hello Eric.

On Fri, 2011-09-23 at 17:17 -0400, Eric Paris wrote:
> On Fri, 2011-09-23 at 23:12 +0200, Guido Trentalancia wrote:
> 
> > You seem to suggest that load_policy -i (and not the kernel) should make
> > sure that init has transitioned to its designated context...
> 
> Can't speak for Justin's system.  

That's for sure. But it seems to me that he already stated that it just
loaded plain refpolicy from git on a plain F15 system. Since we are on
the list he might even confirm once again...

> But that's not what I said.  I said
> it's /sbin/init's problem to make sure it did the right thing and to
> handle errors correctly if it failed.  If Justin has his box enforcing
> and can boot without loading a policy that's a bug and needs to be
> filed.

He has loaded the policy.

The point is that when init does not transition to init_t nothing
happens and the system keeps running with all processes in kernel_t or
insmod_t.

It surely use to happen with upstream components and policy back at the
beginning of this year (I did test that and reported it to the refpolicy
mailing list).

Apparently it also happens with Fedora 15 according to what Justin
reported on here when he started this thread...

Earlier on Daniel Walsh said Fedora and RHEL would crash in such case
(init has not transitioned properly to init_t). I said "very good" (as
that is what I expect from a SELinux system) and asked "how did you
achieved that ?" because I believe such behavior should be definitely be
imported in upstream. But then I thought Daniel's statement doesn't
match with what Justin reported.

Regards,

Guido


--
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.

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Eric Paris]

On Sat, 2011-09-24 at 00:38 +0200, Guido Trentalancia wrote:
> Hello Eric.
> 
> On Fri, 2011-09-23 at 17:17 -0400, Eric Paris wrote:
> > On Fri, 2011-09-23 at 23:12 +0200, Guido Trentalancia wrote:
> > 
> > > You seem to suggest that load_policy -i (and not the kernel) should make
> > > sure that init has transitioned to its designated context...
> > 
> > Can't speak for Justin's system.  
> 
> That's for sure. But it seems to me that he already stated that it just
> loaded plain refpolicy from git on a plain F15 system. Since we are on
> the list he might even confirm once again...
> 
> > But that's not what I said.  I said
> > it's /sbin/init's problem to make sure it did the right thing and to
> > handle errors correctly if it failed.  If Justin has his box enforcing
> > and can boot without loading a policy that's a bug and needs to be
> > filed.
> 
> He has loaded the policy.
> 
> The point is that when init does not transition to init_t nothing
> happens and the system keeps running with all processes in kernel_t or
> insmod_t.
> 
> It surely use to happen with upstream components and policy back at the
> beginning of this year (I did test that and reported it to the refpolicy
> mailing list).
> 
> Apparently it also happens with Fedora 15 according to what Justin
> reported on here when he started this thread...
> 
> Earlier on Daniel Walsh said Fedora and RHEL would crash in such case
> (init has not transitioned properly to init_t).

Ahhh, different than I was talking sorry.  In upstream systemd git the
code in question looks like so:

               /* Transition to the new context */
               r = label_get_create_label_from_exe(SYSTEMD_BINARY_PATH, &label);
               if (r < 0 || label == NULL) {
                       log_open();
                       log_error("Failed to compute init label, ignoring.");
               } else {
                       r = setcon(label);

                       log_open();
                       if (r < 0)
                               log_error("Failed to transition into init label '%s', ignoring.", label);

                       label_free(label);
               }

sds, what do you think, should we make these?  We do know the requisite
enforce state in this function...

-Eric


--
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.

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/23/2011 07:12 PM, Eric Paris wrote:
> On Sat, 2011-09-24 at 00:38 +0200, Guido Trentalancia wrote:
>> Hello Eric.
>> 
>> On Fri, 2011-09-23 at 17:17 -0400, Eric Paris wrote:
>>> On Fri, 2011-09-23 at 23:12 +0200, Guido Trentalancia wrote:
>>> 
>>>> You seem to suggest that load_policy -i (and not the kernel)
>>>> should make sure that init has transitioned to its designated
>>>> context...
>>> 
>>> Can't speak for Justin's system.
>> 
>> That's for sure. But it seems to me that he already stated that
>> it just loaded plain refpolicy from git on a plain F15 system.
>> Since we are on the list he might even confirm once again...
>> 
>>> But that's not what I said.  I said it's /sbin/init's problem
>>> to make sure it did the right thing and to handle errors
>>> correctly if it failed.  If Justin has his box enforcing and
>>> can boot without loading a policy that's a bug and needs to be 
>>> filed.
>> 
>> He has loaded the policy.
>> 
>> The point is that when init does not transition to init_t
>> nothing happens and the system keeps running with all processes
>> in kernel_t or insmod_t.
>> 
>> It surely use to happen with upstream components and policy back
>> at the beginning of this year (I did test that and reported it to
>> the refpolicy mailing list).
>> 
>> Apparently it also happens with Fedora 15 according to what
>> Justin reported on here when he started this thread...
>> 
>> Earlier on Daniel Walsh said Fedora and RHEL would crash in such
>> case (init has not transitioned properly to init_t).
> 
> Ahhh, different than I was talking sorry.  In upstream systemd git
> the code in question looks like so:
> 
> /* Transition to the new context */ r =
> label_get_create_label_from_exe(SYSTEMD_BINARY_PATH, &label); if (r
> < 0 || label == NULL) { log_open(); log_error("Failed to compute
> init label, ignoring."); } else { r = setcon(label);
> 
> log_open(); if (r < 0) log_error("Failed to transition into init
> label '%s', ignoring.", label);
> 
> label_free(label); }
> 
> sds, what do you think, should we make these?  We do know the
> requisite enforce state in this function...
> 
> -Eric
> 
> 
> -- 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.
> 
> 

The failure is in the init load_policy.  It should crash if this
fails.  If anything fails after that is is out of SELinux hands I
believe, since you are not sure what the policy writers intention was.

I believe we would get to this state if the policy writer wanted to
run systemd in the initial state (kernel_t) and not transition.

But maybe on failure of this call we should fail the machine in
enforcing mode.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6AgFEACgkQrlYvE4MpobNv/gCePhYLKIR966T7TLaJIj3hx6Ho
0EQAoNfIpEQSEKPYIdGRg5qC3xlc2dfM
=zG/t
-----END PGP SIGNATURE-----

--
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.

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Stephen Smalley]

On Fri, 2011-09-23 at 19:12 -0400, Eric Paris wrote:
> On Sat, 2011-09-24 at 00:38 +0200, Guido Trentalancia wrote:
> > Hello Eric.
> > 
> > On Fri, 2011-09-23 at 17:17 -0400, Eric Paris wrote:
> > > On Fri, 2011-09-23 at 23:12 +0200, Guido Trentalancia wrote:
> > > 
> > > > You seem to suggest that load_policy -i (and not the kernel) should make
> > > > sure that init has transitioned to its designated context...
> > > 
> > > Can't speak for Justin's system.  
> > 
> > That's for sure. But it seems to me that he already stated that it just
> > loaded plain refpolicy from git on a plain F15 system. Since we are on
> > the list he might even confirm once again...
> > 
> > > But that's not what I said.  I said
> > > it's /sbin/init's problem to make sure it did the right thing and to
> > > handle errors correctly if it failed.  If Justin has his box enforcing
> > > and can boot without loading a policy that's a bug and needs to be
> > > filed.
> > 
> > He has loaded the policy.
> > 
> > The point is that when init does not transition to init_t nothing
> > happens and the system keeps running with all processes in kernel_t or
> > insmod_t.
> > 
> > It surely use to happen with upstream components and policy back at the
> > beginning of this year (I did test that and reported it to the refpolicy
> > mailing list).
> > 
> > Apparently it also happens with Fedora 15 according to what Justin
> > reported on here when he started this thread...
> > 
> > Earlier on Daniel Walsh said Fedora and RHEL would crash in such case
> > (init has not transitioned properly to init_t).
> 
> Ahhh, different than I was talking sorry.  In upstream systemd git the
> code in question looks like so:
> 
>                /* Transition to the new context */
>                r = label_get_create_label_from_exe(SYSTEMD_BINARY_PATH, &label);
>                if (r < 0 || label == NULL) {
>                        log_open();
>                        log_error("Failed to compute init label, ignoring.");
>                } else {
>                        r = setcon(label);
> 
>                        log_open();
>                        if (r < 0)
>                                log_error("Failed to transition into init label '%s', ignoring.", label);
> 
>                        label_free(label);
>                }
> 
> sds, what do you think, should we make these?  We do know the requisite
> enforce state in this function...

These should be fatal errors if enforcing.

-- 
Stephen Smalley
National Security Agency


--
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.

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Guido Trentalancia]

On Tue, 2011-09-27 at 08:46 -0400, Stephen Smalley wrote:
> On Fri, 2011-09-23 at 19:12 -0400, Eric Paris wrote:
> > On Sat, 2011-09-24 at 00:38 +0200, Guido Trentalancia wrote:
> > > Hello Eric.
> > > 
> > > On Fri, 2011-09-23 at 17:17 -0400, Eric Paris wrote:
> > > > On Fri, 2011-09-23 at 23:12 +0200, Guido Trentalancia wrote:
> > > > 
> > > > > You seem to suggest that load_policy -i (and not the kernel) should make
> > > > > sure that init has transitioned to its designated context...
> > > > 
> > > > Can't speak for Justin's system.  
> > > 
> > > That's for sure. But it seems to me that he already stated that it just
> > > loaded plain refpolicy from git on a plain F15 system. Since we are on
> > > the list he might even confirm once again...
> > > 
> > > > But that's not what I said.  I said
> > > > it's /sbin/init's problem to make sure it did the right thing and to
> > > > handle errors correctly if it failed.  If Justin has his box enforcing
> > > > and can boot without loading a policy that's a bug and needs to be
> > > > filed.
> > > 
> > > He has loaded the policy.
> > > 
> > > The point is that when init does not transition to init_t nothing
> > > happens and the system keeps running with all processes in kernel_t or
> > > insmod_t.
> > > 
> > > It surely use to happen with upstream components and policy back at the
> > > beginning of this year (I did test that and reported it to the refpolicy
> > > mailing list).
> > > 
> > > Apparently it also happens with Fedora 15 according to what Justin
> > > reported on here when he started this thread...
> > > 
> > > Earlier on Daniel Walsh said Fedora and RHEL would crash in such case
> > > (init has not transitioned properly to init_t).
> > 
> > Ahhh, different than I was talking sorry.  In upstream systemd git the
> > code in question looks like so:
> > 
> >                /* Transition to the new context */
> >                r = label_get_create_label_from_exe(SYSTEMD_BINARY_PATH, &label);
> >                if (r < 0 || label == NULL) {
> >                        log_open();
> >                        log_error("Failed to compute init label, ignoring.");
> >                } else {
> >                        r = setcon(label);
> > 
> >                        log_open();
> >                        if (r < 0)
> >                                log_error("Failed to transition into init label '%s', ignoring.", label);
> > 
> >                        label_free(label);
> >                }
> > 
> > sds, what do you think, should we make these?  We do know the requisite
> > enforce state in this function...
> 
> These should be fatal errors if enforcing.

Yes, I agree. Fatal errors and system halt.

This is especially true because the box might not be isolated from the
outside world for network services might be up and running in wrong
contexts.

Thanks.

Guido



--
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.

Re: [refpolicy] pam_selinux(gdm-password:session): Security Context justin:staff_r:insmod_t:s0 Assigned

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/27/2011 12:40 PM, Guido Trentalancia wrote:
> On Tue, 2011-09-27 at 08:46 -0400, Stephen Smalley wrote:
>> On Fri, 2011-09-23 at 19:12 -0400, Eric Paris wrote:
>>> On Sat, 2011-09-24 at 00:38 +0200, Guido Trentalancia wrote:
>>>> Hello Eric.
>>>> 
>>>> On Fri, 2011-09-23 at 17:17 -0400, Eric Paris wrote:
>>>>> On Fri, 2011-09-23 at 23:12 +0200, Guido Trentalancia
>>>>> wrote:
>>>>> 
>>>>>> You seem to suggest that load_policy -i (and not the
>>>>>> kernel) should make sure that init has transitioned to
>>>>>> its designated context...
>>>>> 
>>>>> Can't speak for Justin's system.
>>>> 
>>>> That's for sure. But it seems to me that he already stated
>>>> that it just loaded plain refpolicy from git on a plain F15
>>>> system. Since we are on the list he might even confirm once
>>>> again...
>>>> 
>>>>> But that's not what I said.  I said it's /sbin/init's
>>>>> problem to make sure it did the right thing and to handle
>>>>> errors correctly if it failed.  If Justin has his box
>>>>> enforcing and can boot without loading a policy that's a
>>>>> bug and needs to be filed.
>>>> 
>>>> He has loaded the policy.
>>>> 
>>>> The point is that when init does not transition to init_t
>>>> nothing happens and the system keeps running with all
>>>> processes in kernel_t or insmod_t.
>>>> 
>>>> It surely use to happen with upstream components and policy
>>>> back at the beginning of this year (I did test that and
>>>> reported it to the refpolicy mailing list).
>>>> 
>>>> Apparently it also happens with Fedora 15 according to what
>>>> Justin reported on here when he started this thread...
>>>> 
>>>> Earlier on Daniel Walsh said Fedora and RHEL would crash in
>>>> such case (init has not transitioned properly to init_t).
>>> 
>>> Ahhh, different than I was talking sorry.  In upstream systemd
>>> git the code in question looks like so:
>>> 
>>> /* Transition to the new context */ r =
>>> label_get_create_label_from_exe(SYSTEMD_BINARY_PATH, &label); 
>>> if (r < 0 || label == NULL) { log_open(); log_error("Failed to
>>> compute init label, ignoring."); } else { r = setcon(label);
>>> 
>>> log_open(); if (r < 0) log_error("Failed to transition into
>>> init label '%s', ignoring.", label);
>>> 
>>> label_free(label); }
>>> 
>>> sds, what do you think, should we make these?  We do know the
>>> requisite enforce state in this function...
>> 
>> These should be fatal errors if enforcing.
> 
> Yes, I agree. Fatal errors and system halt.
> 
> This is especially true because the box might not be isolated from
> the outside world for network services might be up and running in
> wrong contexts.
> 
> Thanks.
> 
> Guido
> 
> 
> 
> -- 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.


Please open a bugzilla, always better coming from outside of Red Hat
and CC eric and me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6CD0YACgkQrlYvE4MpobNF/ACg3qPSOhiTUj0JlUfhJVA9X5tY
O/gAn1U4EWHloCQXY3prySxS9HjtPoNb
=oC9z
-----END PGP SIGNATURE-----

--
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.