Hello Chris and Dom,
Please hold on this patch. I am now puzzled at if we should have crond use pam_namespace.so at all.
The problem I run into is that the cron job process does not share the same namespace with the cron job submitter's process.
If a staff user(mapped to staff_u) specifies cron job to write into a "/home/staff/somefile", if $HOME is polyinstantiated, then the cron job process will attempt to write into somefile to the BASE directory of /home/staff, rather than the MEMBER directory of /home/home.inst/staff_xxx created by ssh or login, resulting that this somefile is invisible to the staff user, only the root user could see it in the original base directory of /home/staff.
How could I have the cron job process share the same namespace with the user's login session?
Would below plan ever work?
1. when crontab command creates user's cron job files in /var/spool/cron, the file name not only contains user's Linux User name, but also the submitter's role and MLS level;
2. crond determines cron job process security context from the name of above cron job files, rather than by get_default_context_with_level(). The cron job process will be in the same security context as the relevant submitter, rather than cronjob_t fetched from system_r:crond_t:s0 related entries in contexts/default_contexts or users/[user].
3. crond PAM configs uses pam_namespace.so, which will find the cron job submitter's polyinstantiation member directory already created by ssh or login in the polyinstantiation parent directory.
Thanks,
Harry
From: [email protected]
To: cpebenito at tresys.com; refpolicy at oss1.tresys.com
Date: Fri, 11 Feb 2011 08:54:29 +0000
Subject: [refpolicy] Make crond able to use pam_namespace.so
Hi Chirs,
Another patch for crond_t, call the files_polyinstantiate_all() interface for it as what has been done for other entrypoint applications' domains, so that crond could work well when pam_namespace.so is used in its PAM config files and polyinstantiation is enabled.
Thanks,
Best regards,
Harry
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110213/2369fc73/attachment.html
On Sun, Feb 13, 2011 at 10:46:32AM +0000, HarryCiao wrote:
>
>
>
>
> Hello Chris and Dom,
>
> Please hold on this patch. I am now puzzled at if we should have crond use pam_namespace.so at all.
>
> The problem I run into is that the cron job process does not share the same namespace with the cron job submitter's process.
>
> If a staff user(mapped to staff_u) specifies cron job to write into a "/home/staff/somefile", if $HOME is polyinstantiated, then the cron job process will attempt to write into somefile to the BASE directory of /home/staff, rather than the MEMBER directory of /home/home.inst/staff_xxx created by ssh or login, resulting that this somefile is invisible to the staff user, only the root user could see it in the original base directory of /home/staff.
>
> How could I have the cron job process share the same namespace with the user's login session?
>
> Would below plan ever work?
> 1. when crontab command creates user's cron job files in /var/spool/cron, the file name not only contains user's Linux User name, but also the submitter's role and MLS level;
>
> 2. crond determines cron job process security context from the name of above cron job files, rather than by get_default_context_with_level(). The cron job process will be in the same security context as the relevant submitter, rather than cronjob_t fetched from system_r:crond_t:s0 related entries in contexts/default_contexts or users/[user].
>
> 3. crond PAM configs uses pam_namespace.so, which will find the cron job submitter's polyinstantiation member directory already created by ssh or login in the polyinstantiation parent directory.
I am not sure but i use to have similar issues which in the end were never resolved.
https://bugzilla.redhat.com/show_bug.cgi?id=519232
>
>
> Thanks,
> Harry
>
> From: harrytaurus2002 at hotmail.com
> To: cpebenito at tresys.com; refpolicy at oss1.tresys.com
> Date: Fri, 11 Feb 2011 08:54:29 +0000
> Subject: [refpolicy] Make crond able to use pam_namespace.so
>
>
>
>
>
>
>
>
> Hi Chirs,
>
> Another patch for crond_t, call the files_polyinstantiate_all() interface for it as what has been done for other entrypoint applications' domains, so that crond could work well when pam_namespace.so is used in its PAM config files and polyinstantiation is enabled.
>
> Thanks,
>
> Best regards,
> Harry
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110213/922f3abd/attachment.bin
Hello Dom,
Yep, we have been in the same situation here!
xdm_t, sshd_t, local_login_t etc are all entrypoint domains and could establish login sessions. The problem is that the instance member directory created by one kind of entrypoint application can not be shared with another. I guess in your case the instantiated home directory created by sshd_t is different than the one created by gnome(in different namespace), that's why the pki can't be shared.
I am wondering if using the "unmnt_remnt" option for pam_namespace.so in sshd PAM files could ever help your case, the sshd should unbind any member directory from the poly dir and then bind it on its own, so that no matter if gnome is started or not sshd would always save and then find the pki in the same one instantiated member home directory.
While my problem really is to make crond_t reuse any existing instantiated home directory created by other entrypoint applications such as sshd_t or local_login_t.
Best regards,
Harry
Date: Sun, 13 Feb 2011 13:10:58 +0100
From: [email protected]
To: refpolicy at oss1.tresys.com
Subject: Re: [refpolicy] Make crond able to use pam_namespace.so
On Sun, Feb 13, 2011 at 10:46:32AM +0000, HarryCiao wrote:
>
>
>
>
> Hello Chris and Dom,
>
> Please hold on this patch. I am now puzzled at if we should have crond use pam_namespace.so at all.
>
> The problem I run into is that the cron job process does not share the same namespace with the cron job submitter's process.
>
> If a staff user(mapped to staff_u) specifies cron job to write into a "/home/staff/somefile", if $HOME is polyinstantiated, then the cron job process will attempt to write into somefile to the BASE directory of /home/staff, rather than the MEMBER directory of /home/home.inst/staff_xxx created by ssh or login, resulting that this somefile is invisible to the staff user, only the root user could see it in the original base directory of /home/staff.
>
> How could I have the cron job process share the same namespace with the user's login session?
>
> Would below plan ever work?
> 1. when crontab command creates user's cron job files in /var/spool/cron, the file name not only contains user's Linux User name, but also the submitter's role and MLS level;
>
> 2. crond determines cron job process security context from the name of above cron job files, rather than by get_default_context_with_level(). The cron job process will be in the same security context as the relevant submitter, rather than cronjob_t fetched from system_r:crond_t:s0 related entries in contexts/default_contexts or users/[user].
>
> 3. crond PAM configs uses pam_namespace.so, which will find the cron job submitter's polyinstantiation member directory already created by ssh or login in the polyinstantiation parent directory.
I am not sure but i use to have similar issues which in the end were never resolved.
https://bugzilla.redhat.com/show_bug.cgi?id=519232
>
>
> Thanks,
> Harry
>
> From: harrytaurus2002 at hotmail.com
> To: cpebenito at tresys.com; refpolicy at oss1.tresys.com
> Date: Fri, 11 Feb 2011 08:54:29 +0000
> Subject: [refpolicy] Make crond able to use pam_namespace.so
>
>
>
>
>
>
>
>
> Hi Chirs,
>
> Another patch for crond_t, call the files_polyinstantiate_all() interface for it as what has been done for other entrypoint applications' domains, so that crond could work well when pam_namespace.so is used in its PAM config files and polyinstantiation is enabled.
>
> Thanks,
>
> Best regards,
> Harry
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110214/0ecf0a4f/attachment.html
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/13/2011 11:37 PM, HarryCiao wrote:
> Hello Dom,
>
> Yep, we have been in the same situation here!
>
> xdm_t, sshd_t, local_login_t etc are all entrypoint domains and could
> establish login sessions. The problem is that the instance member
> directory created by one kind of entrypoint application can not be
> shared with another. I guess in your case the instantiated home
> directory created by sshd_t is different than the one created by
> gnome(in different namespace), that's why the pki can't be shared.
>
> I am wondering if using the "unmnt_remnt" option for pam_namespace.so in
> sshd PAM files could ever help your case, the sshd should unbind any
> member directory from the poly dir and then bind it on its own, so that
> no matter if gnome is started or not sshd would always save and then
> find the pki in the same one instantiated member home directory.
>
> While my problem really is to make crond_t reuse any existing
> instantiated home directory created by other entrypoint applications
> such as sshd_t or loc al_login_t.
>
> Best regards,
> Harry
>
>
> Date: Sun, 13 Feb 2011 13:10:58 +0100
> From: domg472 at gmail.com
> To: refpolicy at oss1.tresys.com
> Subject: Re: [refpolicy] Make crond able to use pam_namespace.so
>
> On Sun, Feb 13, 2011 at 10:46:32AM +0000, HarryCiao wrote:
>>
>>
>>
>>
>> Hello Chris and Dom,
>>
>> Please hold on this patch. I am now puzzled at if we should have crond use pam_namespace.so at all.
>>
>> The problem I run into is that the cron job process does not share the same namespace with the cron job submitter's process.
>>
>> If a staff user(mapped to staff_u) specifies cron job to write into a "/home/staff/somefile", if $HOME is polyinstantiated, then the cron job process will attempt to write into somefile to the BASE directory of /home/staff, rather than the MEMBER directory of /home/home.inst/staff_xxx created by ssh or login, resulting that this somefile is invisible to
> the staff user, only the root user could see it in the original base directory of /home/staff.
>>
>> How could I have the cron job process share the same namespace with the user's login session?
>>
>> Would below plan ever work?
>> 1. when crontab command creates user's cron job files in /var/spool/cron, the file name not only contains user's Linux User name, but also the submitter's role and MLS level;
>>
>> 2. crond determines cron job process security context from the name of above cron job files, rather than by get_default_context_with_level(). The cron job process will be in the same security context as the relevant submitter, rather than cronjob_t fetched from system_r:crond_t:s0 related entries in contexts/default_contexts or users/[user].
>>
>> 3. crond PAM configs uses pam_namespace.so, which will find the cron job submitter's polyinstantiation member directory already created by ssh or login in the polyinstantiation
> parent directory.
>
> I am not sure but i use to have similar issues which in the end were never resolved.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=519232
>
>
>>
>>
>> Thanks,
>> Harry
>>
>> From: harrytaurus2002 at hotmail.com
>> To: cpebenito at tresys.com; refpolicy at oss1.tresys.com
>> Date: Fri, 11 Feb 2011 08:54:29 +0000
>> Subject: [refpolicy] Make crond able to use pam_namespace.so
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi Chirs,
>>
>> Another patch for crond_t, call the files_polyinstantiate_all() interface for it as what has been done for other entrypoint applications' domains, so that crond could work well when pam_namespace.so is used in its PAM config files and polyinstantiation is enabled.
>>
>> Thanks,
>>
>> Best regards,
>> Harry
>>
>
>>
>> _______________________________________________
>> refpolicy mailing list
>> refpolicy at oss.tresys.com
>> http://oss.tresys.com/mailman/listinfo/refpolicy
>
>
> _______________________________________________ refpolicy mailing list
> refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
>
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
I think this discussion should take place on the selinux list instead of
the refpolicy list.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
iEYEARECAAYFAk1ZSdwACgkQrlYvE4MpobOp1wCfb/Kp/KYcGWRUU8h/xmp6W6bf
60IAoOrZov7CkQPlELmTIOCn7cfwLpii
=SvEK
-----END PGP SIGNATURE-----
Hello Chirs and Dom,
My crond problem seems to have been fixed, the attached are the revised patches for crond_t in order to support pam_login.so and pam_namespace.so in crond PAM files.
The test logs is also attached, we can see that the cronjob process could write into the HOME instance memberdir for the root user, who logs in with the default MLS range via login that enables polyinstantiation.
BTW, crond really has nowhere to know the role or MLS level assumed by a user, we may have to relay such information to crond if we would like to have cronjob always able to write into user's HOME memberdir when the user is logging in with a random MLS level.
Thanks!
Best regards,
Harry
> Date: Mon, 14 Feb 2011 10:27:26 -0500
> From: dwalsh at redhat.com
> To: harrytaurus2002 at hotmail.com
> CC: domg472 at gmail.com; refpolicy at oss1.tresys.com
> Subject: Re: [refpolicy] Make crond able to use pam_namespace.so
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 02/13/2011 11:37 PM, HarryCiao wrote:
> > Hello Dom,
> >
> > Yep, we have been in the same situation here!
> >
> > xdm_t, sshd_t, local_login_t etc are all entrypoint domains and could
> > establish login sessions. The problem is that the instance member
> > directory created by one kind of entrypoint application can not be
> > shared with another. I guess in your case the instantiated home
> > directory created by sshd_t is different than the one created by
> > gnome(in different namespace), that's why the pki can't be shared.
> >
> > I am wondering if using the "unmnt_remnt" option for pam_namespace.so in
> > sshd PAM files could ever help your case, the sshd should unbind any
> > member directory from the poly dir and then bind it on its own, so that
> > no matter if gnome is started or not sshd would always save and then
> > find the pki in the same one instantiated member home directory.
> >
> > While my problem really is to make crond_t reuse any existing
> > instantiated home directory created by other entrypoint applications
> > such as sshd_t or loc al_login_t.
> >
> > Best regards,
> > Harry
> >
> >
> > Date: Sun, 13 Feb 2011 13:10:58 +0100
> > From: domg472 at gmail.com
> > To: refpolicy at oss1.tresys.com
> > Subject: Re: [refpolicy] Make crond able to use pam_namespace.so
> >
> > On Sun, Feb 13, 2011 at 10:46:32AM +0000, HarryCiao wrote:
> >>
> >>
> >>
> >>
> >> Hello Chris and Dom,
> >>
> >> Please hold on this patch. I am now puzzled at if we should have crond use pam_namespace.so at all.
> >>
> >> The problem I run into is that the cron job process does not share the same namespace with the cron job submitter's process.
> >>
> >> If a staff user(mapped to staff_u) specifies cron job to write into a "/home/staff/somefile", if $HOME is polyinstantiated, then the cron job process will attempt to write into somefile to the BASE directory of /home/staff, rather than the MEMBER directory of /home/home.inst/staff_xxx created by ssh or login, resulting that this somefile is invisible to
> > the staff user, only the root user could see it in the original base directory of /home/staff.
> >>
> >> How could I have the cron job process share the same namespace with the user's login session?
> >>
> >> Would below plan ever work?
> >> 1. when crontab command creates user's cron job files in /var/spool/cron, the file name not only contains user's Linux User name, but also the submitter's role and MLS level;
> >>
> >> 2. crond determines cron job process security context from the name of above cron job files, rather than by get_default_context_with_level(). The cron job process will be in the same security context as the relevant submitter, rather than cronjob_t fetched from system_r:crond_t:s0 related entries in contexts/default_contexts or users/[user].
> >>
> >> 3. crond PAM configs uses pam_namespace.so, which will find the cron job submitter's polyinstantiation member directory already created by ssh or login in the polyinstantiation
> > parent directory.
> >
> > I am not sure but i use to have similar issues which in the end were never resolved.
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=519232
> >
> >
> >>
> >>
> >> Thanks,
> >> Harry
> >>
> >> From: harrytaurus2002 at hotmail.com
> >> To: cpebenito at tresys.com; refpolicy at oss1.tresys.com
> >> Date: Fri, 11 Feb 2011 08:54:29 +0000
> >> Subject: [refpolicy] Make crond able to use pam_namespace.so
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> Hi Chirs,
> >>
> >> Another patch for crond_t, call the files_polyinstantiate_all() interface for it as what has been done for other entrypoint applications' domains, so that crond could work well when pam_namespace.so is used in its PAM config files and polyinstantiation is enabled.
> >>
> >> Thanks,
> >>
> >> Best regards,
> >> Harry
> >>
> >
> >>
> >> _______________________________________________
> >> refpolicy mailing list
> >> refpolicy at oss.tresys.com
> >> http://oss.tresys.com/mailman/listinfo/refpolicy
> >
> >
> > _______________________________________________ refpolicy mailing list
> > refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy
> >
> >
> >
> > _______________________________________________
> > refpolicy mailing list
> > refpolicy at oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
>
> I think this discussion should take place on the selinux list instead of
> the refpolicy list.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAk1ZSdwACgkQrlYvE4MpobOp1wCfb/Kp/KYcGWRUU8h/xmp6W6bf
> 60IAoOrZov7CkQPlELmTIOCn7cfwLpii
> =SvEK
> -----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110216/c047c0ab/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-v2-crond-polyinstantiate-all.patch
Type: text/x-patch
Size: 1218 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110216/c047c0ab/attachment-0002.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-v2-crond-uses-pam_loginuid.patch
Type: text/x-patch
Size: 1274 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110216/c047c0ab/attachment-0003.bin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: crond_polyinstant_log
Type: application/octet-stream
Size: 6711 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110216/c047c0ab/attachment-0001.obj