A new release of the SELinux Reference Policy is now available on
the Tresys OSS site, http://oss.tresys.com. This release primarily
focused on general maintenance.
The complete change log for this release follows at the end of the
email.
For people interested in helping Reference Policy development, the X
desktop and role separation needs testing, in addition to general
testing.
* Tue Jul 26 2011 Chris PeBenito <[email protected]> - 2.20110726
- Fix role declarations to handle role attribute compilers.
- Rename audioentropy module to entropyd due to haveged support.
- Add haveged support from Sven Vermeulen.
- Authentication file patch from Matthew Ife.
- Add agent support to zabbix from Sven Vermeulen.
- Cyrus file context update for Gentoo from Corentin Labbe.
- Portage updates from Sven Vermeulen.
- Fix init_system_domain() description, pointed out by Elia Pinto.
- Postgresql selabel_lookup update from KaiGai Kohei.
- Dovecot managesieve support from Mika Pfluger.
- Semicolon after interface/template calls cleanup from Elia Pinto.
- Gentoo courier updates from Sven Vermeulen.
- Amavis patch for connecting to nslcd from Miroslav Grepl.
- Shorewall patch from Miroslav Grepl.
- Cpufreqselector dbus patch from Guido Trentalancia.
- Cron pam_namespace and pam_loginuid support from Harry Ciao.
- Xserver update for startx from Sven Vermeulen.
- Fix MLS constraint for contains permission from Harry Ciao.
- Apache user webpages fix from Dominick Grift.
- Change default build.conf to modular policy from Stephen Smalley.
- Xen refinement patch from Stephen Smalley.
- Sudo timestamp file location update from Sven Vermeulen.
- XServer keyboard event patch from Sven Vermeulen.
- RAID uevent patch from Sven Vermeulen.
- Gentoo ALSA init script usage patch from Sven Vermeulen.
- LVM semaphore usage patch from Sven Vermeulen.
- Module load request patch for insmod from Sven Vermeulen.
- Cron default contexts fix from Harry Ciao.
- Man page fixes from Justin Mattock.
- Add syslog capability.
- Support for logging in to /dev/console, from Harry Ciao.
- Database object class updates and associated SEPostgreSQL changes from
KaiGai Kohei.
- IPSEC SPD and Hadoop IPSEC updates from Paul Nuzzi.
- Mount updates from Harry Ciao.
- Semanage update for MLS systems from Harry Ciao.
- Vlock terminal use update from Harry Ciao.
- Hadoop CDH3 updates from Paul Nuzzi.
- Add sepgsql_contexts appconfig files from KaiGai Kohei.
- Added modules:
aiccu
bugzilla (Dan Walsh)
colord (Dan Walsh)
cmirrord (Miroslav Grepl)
mediawiki (Miroslav Grepl)
mpd (Miroslav Grepl)
ncftool
passenger (Miroslav Grepl)
qpid (Dan Walsh)
samhain (Harry Ciao)
telepathy (Dominick Grift)
tcsd (Stephen Smalley)
vnstatd (Dan Walsh)
zarafa (Miroslav Grepl)
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
Thanks very much Christopher for the new release !
Just a quick reminder that it seems to me that latest git (and thus
implicitly the new release), do not cater proper file contexts
definitions yet for new udev directory /run.
Latest udev releases are moving from /dev/.udev to /run (still optional
at this transition stage but perhaps it will become mandatory one day).
In terms of release numbers should be at least any udev-17? (but
possibly also some of the udev-16?).
At the moment, I see:
# ls -lZ /dev/.udev/
drwxr-xr-x. root root system_u:object_r:udev_tbl_t:s0
...
# grep ^/run policy/modules/kernel/files.fc
/run -d gen_context(system_u:object_r:var_run_t,s0-mls_systemhigh)
/run/.* gen_context(system_u:object_r:var_run_t,s0)
/run/.*\.*pid <<none>>
/run/lock(/.*)? gen_context(system_u:object_r:var_lock_t,s0)
# grep ^/var\/run policy/modules/kernel/files.fc
/var/run -d gen_context(system_u:object_r:var_run_t,s0-mls_systemhigh)
/var/run -l gen_context(system_u:object_r:var_run_t,s0)
/var/run/.* gen_context(system_u:object_r:var_run_t,s0)
/var/run/.*\.*pid <<none>>
/var/run/motd -- gen_context(system_u:object_r:etc_runtime_t,s0)
If the above is confirmed, we have an inconsistency for /run because it would
just be a duplicate for /var/run which potentially conflicts with new udev.
Regards,
Guido
On Tue, 2011-07-26 at 14:44 -0400, Christopher J. PeBenito wrote:
> A new release of the SELinux Reference Policy is now available on
> the Tresys OSS site, http://oss.tresys.com. This release primarily
> focused on general maintenance.
>
> The complete change log for this release follows at the end of the
> email.
>
> For people interested in helping Reference Policy development, the X
> desktop and role separation needs testing, in addition to general
> testing.
>
> * Tue Jul 26 2011 Chris PeBenito <[email protected]> - 2.20110726
> - Fix role declarations to handle role attribute compilers.
> - Rename audioentropy module to entropyd due to haveged support.
> - Add haveged support from Sven Vermeulen.
> - Authentication file patch from Matthew Ife.
> - Add agent support to zabbix from Sven Vermeulen.
> - Cyrus file context update for Gentoo from Corentin Labbe.
> - Portage updates from Sven Vermeulen.
> - Fix init_system_domain() description, pointed out by Elia Pinto.
> - Postgresql selabel_lookup update from KaiGai Kohei.
> - Dovecot managesieve support from Mika Pfluger.
> - Semicolon after interface/template calls cleanup from Elia Pinto.
> - Gentoo courier updates from Sven Vermeulen.
> - Amavis patch for connecting to nslcd from Miroslav Grepl.
> - Shorewall patch from Miroslav Grepl.
> - Cpufreqselector dbus patch from Guido Trentalancia.
> - Cron pam_namespace and pam_loginuid support from Harry Ciao.
> - Xserver update for startx from Sven Vermeulen.
> - Fix MLS constraint for contains permission from Harry Ciao.
> - Apache user webpages fix from Dominick Grift.
> - Change default build.conf to modular policy from Stephen Smalley.
> - Xen refinement patch from Stephen Smalley.
> - Sudo timestamp file location update from Sven Vermeulen.
> - XServer keyboard event patch from Sven Vermeulen.
> - RAID uevent patch from Sven Vermeulen.
> - Gentoo ALSA init script usage patch from Sven Vermeulen.
> - LVM semaphore usage patch from Sven Vermeulen.
> - Module load request patch for insmod from Sven Vermeulen.
> - Cron default contexts fix from Harry Ciao.
> - Man page fixes from Justin Mattock.
> - Add syslog capability.
> - Support for logging in to /dev/console, from Harry Ciao.
> - Database object class updates and associated SEPostgreSQL changes from
> KaiGai Kohei.
> - IPSEC SPD and Hadoop IPSEC updates from Paul Nuzzi.
> - Mount updates from Harry Ciao.
> - Semanage update for MLS systems from Harry Ciao.
> - Vlock terminal use update from Harry Ciao.
> - Hadoop CDH3 updates from Paul Nuzzi.
> - Add sepgsql_contexts appconfig files from KaiGai Kohei.
> - Added modules:
> aiccu
> bugzilla (Dan Walsh)
> colord (Dan Walsh)
> cmirrord (Miroslav Grepl)
> mediawiki (Miroslav Grepl)
> mpd (Miroslav Grepl)
> ncftool
> passenger (Miroslav Grepl)
> qpid (Dan Walsh)
> samhain (Harry Ciao)
> telepathy (Dominick Grift)
> tcsd (Stephen Smalley)
> vnstatd (Dan Walsh)
> zarafa (Miroslav Grepl)
>
>
On Tue 26 Jul 20:07:29 2011, Guido Trentalancia wrote:
> Thanks very much Christopher for the new release !
>
> Just a quick reminder that it seems to me that latest git (and thus
> implicitly the new release), do not cater proper file contexts
> definitions yet for new udev directory /run.
Git refpolicy and the new release contain:
/var/run/udev(/.*)? gen_context(system_u:object_r:udev_tbl_t,s0)
As explained in the relevant commit message, this is intended to label
/run/udev rather than /var/run/udev.
You need to use some method outside the refpolicy to ensure that
directories in /run are labelled the same as the corresponding
directories in /var/run. The easiest is to put
/run /var/run
in /etc/selinux/$NAME/contexts/files/file_contexts.subs.
> Latest udev releases are moving from /dev/.udev to /run (still optional
> at this transition stage but perhaps it will become mandatory one day).
>
> In terms of release numbers should be at least any udev-17? (but
> possibly also some of the udev-16?).
>
> At the moment, I see:
>
> # ls -lZ /dev/.udev/
> drwxr-xr-x. root root system_u:object_r:udev_tbl_t:s0
> ...
>
> # grep ^/run policy/modules/kernel/files.fc
> /run -d gen_context(system_u:object_r:var_run_t,s0-mls_systemhigh)
> /run/.* gen_context(system_u:object_r:var_run_t,s0)
> /run/.*\.*pid <<none>>
> /run/lock(/.*)? gen_context(system_u:object_r:var_lock_t,s0)
>
> # grep ^/var\/run policy/modules/kernel/files.fc
> /var/run -d gen_context(system_u:object_r:var_run_t,s0-mls_systemhigh)
> /var/run -l gen_context(system_u:object_r:var_run_t,s0)
> /var/run/.* gen_context(system_u:object_r:var_run_t,s0)
> /var/run/.*\.*pid <<none>>
> /var/run/motd -- gen_context(system_u:object_r:etc_runtime_t,s0)
>
> If the above is confirmed, we have an inconsistency for /run because it would
> just be a duplicate for /var/run which potentially conflicts with new udev.
/run is supposed to be a duplicate of /var/run (they should be the
same directory via either a symlink or a bind mount). Refpolicy
currently does not have fcs for /run so you need to use
file_contexts.subs as above to label /run. As an alternative method,
in the Debian policy, Russell used Perl to add duplicates of all the
/var/run lines with /run instead.
Best wishes,
Martin Orr
Oh yes and the commit was exactly from you on Jul 18th ! Thanks very
much Martin !
I didn't notice that, because I was matching against ^/run.
It's all explained now, sorry to the list about the confusion.
Regards,
Guido
On Wed, 2011-07-27 at 20:47 +0100, Martin Orr wrote:
> On Tue 26 Jul 20:07:29 2011, Guido Trentalancia wrote:
>
> > Thanks very much Christopher for the new release !
> >
> > Just a quick reminder that it seems to me that latest git (and thus
> > implicitly the new release), do not cater proper file contexts
> > definitions yet for new udev directory /run.
>
> Git refpolicy and the new release contain:
> /var/run/udev(/.*)? gen_context(system_u:object_r:udev_tbl_t,s0)
>
> As explained in the relevant commit message, this is intended to label
> /run/udev rather than /var/run/udev.
>
> You need to use some method outside the refpolicy to ensure that
> directories in /run are labelled the same as the corresponding
> directories in /var/run. The easiest is to put
> /run /var/run
> in /etc/selinux/$NAME/contexts/files/file_contexts.subs.
>
> > Latest udev releases are moving from /dev/.udev to /run (still optional
> > at this transition stage but perhaps it will become mandatory one day).
> >
> > In terms of release numbers should be at least any udev-17? (but
> > possibly also some of the udev-16?).
> >
> > At the moment, I see:
> >
> > # ls -lZ /dev/.udev/
> > drwxr-xr-x. root root system_u:object_r:udev_tbl_t:s0
> > ...
> >
> > # grep ^/run policy/modules/kernel/files.fc
> > /run -d gen_context(system_u:object_r:var_run_t,s0-mls_systemhigh)
> > /run/.* gen_context(system_u:object_r:var_run_t,s0)
> > /run/.*\.*pid <<none>>
> > /run/lock(/.*)? gen_context(system_u:object_r:var_lock_t,s0)
> >
> > # grep ^/var\/run policy/modules/kernel/files.fc
> > /var/run -d gen_context(system_u:object_r:var_run_t,s0-mls_systemhigh)
> > /var/run -l gen_context(system_u:object_r:var_run_t,s0)
> > /var/run/.* gen_context(system_u:object_r:var_run_t,s0)
> > /var/run/.*\.*pid <<none>>
> > /var/run/motd -- gen_context(system_u:object_r:etc_runtime_t,s0)
> >
> > If the above is confirmed, we have an inconsistency for /run because it would
> > just be a duplicate for /var/run which potentially conflicts with new udev.
>
> /run is supposed to be a duplicate of /var/run (they should be the
> same directory via either a symlink or a bind mount). Refpolicy
> currently does not have fcs for /run so you need to use
> file_contexts.subs as above to label /run. As an alternative method,
> in the Debian policy, Russell used Perl to add duplicates of all the
> /var/run lines with /run instead.
>
> Best wishes,
> Martin Orr
>
On 07/27/11 15:47, Martin Orr wrote:
> On Tue 26 Jul 20:07:29 2011, Guido Trentalancia wrote:
>
>> Thanks very much Christopher for the new release !
>>
>> Just a quick reminder that it seems to me that latest git (and thus
>> implicitly the new release), do not cater proper file contexts
>> definitions yet for new udev directory /run.
>
> Git refpolicy and the new release contain:
> /var/run/udev(/.*)? gen_context(system_u:object_r:udev_tbl_t,s0)
>
> As explained in the relevant commit message, this is intended to label
> /run/udev rather than /var/run/udev.
>
> You need to use some method outside the refpolicy to ensure that
> directories in /run are labelled the same as the corresponding
> directories in /var/run. The easiest is to put
> /run /var/run
> in /etc/selinux/$NAME/contexts/files/file_contexts.subs.
This reminds me, I need to add this file to refpolicy to handle known
substitutions.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
Hi Chris,
These days I read through your discussions about rbacsep way back to 2008. At that time you'd pointed out a todo list for full rbac separation support:
1. Kernel's recognition of role_transition rule for non process classes;
2. Role attribute support as in below rbacsep constrain:
constrain { dir file ... } { getattr read write .... }
r1 == r2
or r1 == system_r
or r2 == object_r
or r1 == rbac_subj_role_file_exempt
or r2 == rbac_obj_role_file_exempt
or t1 == rbac_subj_type_file_exempt
or t2 == rbac_obj_type_file_exempt;
3. Add a new "role_change" rule and modify login/newrole program to change controlling terminal's role according to that of user;
4. Add a new "role_member" rule for polyinstantiation support;
5. genhomedircon updated for role;
6. Move the policy to initialize newcontext from security_compute_sid() in kernel up to refpolicy, by introducing new rules such as(suggested by Stephen, not directly related with rbacsep):
role_default {process socket ...} fromsource;
type_default {process socket ...} fromsource;
role_default {file dir ...} fromtarget;
type_default {file dir ...} fromtarget;
Here are my comments and questions:
As for 1, it has been done since we have added the class support to the role_transition rule. Refpolicy could have whatever needed rules added to transition the role of files/dirs from object_r;
As for 2, it has been done too since we have added the role attribute support;
As for 3 & 4, it won't be difficult for us to add these two new rules, but I have not understand clear yet the influence and meanings of the role_change rule, could you explain it a bit more?
Also it seems that you had branched refpolicy to provide the rbacsep constrain and collapse per-role templates such as xxx_sudo_t to sudo_t(where can I get it?) but further run into type_transition conflicts when sudo_t needs to transition back to user's domain:
type_transition sudo_t shell_exec_t:process auditadm_t;
type_transition sudo_t shell_exec_t:process secadm_t;
type_transition sudo_t shell_exec_t:process staff_t;
type_transition sudo_t shell_exec_t:process sysadm_t;
type_transition sudo_t shell_exec_t:process user_t;
You've mentioned since we can't make sudo application SELinux-aware due to their vast differences, we would have to fall back on the per-role template of xxx_sudo_t. (Actually this is the end of your rbacsep effort, right?)
Would it be possible to tackle such condition by introducing a new "type_transition_osid" rule? For example,
type_transition_osid sudo_t shell_exec_t : process;
And in security_compute_sid(), for AVTAB_TRANSITION rules we would search for type_transition_osid rules aside from type_transition rules for the process class. If a matching type_transition_osid rule is found, then newcontext->type would be set to the type from tsec->osid.
If it makes sense, then what else works may have been required aside from it and the above todo list for full rbacsep support?
Thanks,
Harry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110811/db8909d4/attachment.html
On 08/11/11 03:03, HarryCiao wrote:
> Hi Chris,
>
> These days I read through your discussions about rbacsep way back to
> 2008. At that time you'd pointed out a todo list for full rbac
> separation support:
>
> 1. Kernel's recognition of role_transition rule for non process classes;
>
> 2. Role attribute support as in below rbacsep constrain:
>
> constrain { dir file ... } { getattr read write .... }
> r1 == r2
> or r1 == system_r
> or r2 == object_r
> or r1 == rbac_subj_role_file_exempt
> or r2 == rbac_obj_role_file_exempt
> or t1 == rbac_subj_type_file_exempt
> or t2 == rbac_obj_type_file_exempt;
>
> 3. Add a new "role_change" rule and modify login/newrole program to
> change controlling terminal's role according to that of user;
>
> 4. Add a new "role_member" rule for polyinstantiation support;
>
> 5. genhomedircon updated for role;
> *6. Move the policy to initialize newcontext from security_compute_sid()
> in kernel up to refpolicy, by introducing new rules such as(suggested by
> Stephen, not directly related with rbacsep):
>
> role_default {process socket ...} fromsource;
> type_default {process socket ...} fromsource;
> role_default {file dir ...} fromtarget;
> type_default {file dir ...} fromtarget;
I don't remember this one.
> Here are my comments and questions:
>
> As for 1, it has been done since we have added the class support to the
> role_transition rule. Refpolicy could have whatever needed rules added
> to transition the role of files/dirs from object_r;
>
> As for 2, it has been done too since we have added the role attribute
> support;
>
> As for 3 & 4, it won't be difficult for us to add these two new rules,
> but I have not understand clear yet the influence and meanings of the
> role_change rule, could you explain it a bit more?
Well we've had role_change rules since the ancient times. Its purpose
is to inform userspace apps how to relabel a user's terminal when they
change roles.
> Also it seems that you had branched refpolicy to provide the rbac sep
> constrain and collapse per-role templates such as xxx_sudo_t to
> sudo_t(where can I get it?) but further run into type_transition
> conflicts when sudo_t needs to transition back to user's domain:
>
> type_transition sudo_t shell_exec_t:process auditadm_t;
> type_transition sudo_t shell_exec_t:process secadm_t;
> type_transition sudo_t shell_exec_t:process staff_t;
> type_transition sudo_t shell_exec_t:process sysadm_t;
> type_transition sudo_t shell_exec_t:process user_t;
>
> You've mentioned since we can't make sudo application SELinux-aware due
> to their vast differences, we would have to fall back on the per-role
> template of xxx_sudo_t. (Actually this is the end of your rbacsep
> effort, right?)
Correct, thats where we stopped.
> Would it be possible to tackle such condition by introducing a new
> "type_transition_osid" rule? For example,
>
> type_transition_osid sudo_t shell_exec_t : process;
>
> And in security_compute_sid(), for AVTAB_TRANSITION rules we would
> search for type_transition_osid rules aside from type_transition rules
> for the process class. If a matching type_transition_osid rule is found,
> then newcontext->type would be set to the type from tsec->osid.
>
> If it makes sense, then what else works may have been required aside
> from it and the above todo list for full rbacsep support?
We don't need to add anything special; we have the same problem with
ubacsep, and solved it by retaining the per-role domains, eg. user_su_t,
sysadm_sudo_t, etc.
When we restart, it don't think it will be nearly as much work, since
all of the collapsing was done for ubacsep.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On 08/12/11 08:42, Christopher J. PeBenito wrote:
> On 08/11/11 03:03, HarryCiao wrote:
>> Hi Chris,
>>
>> These days I read through your discussions about rbacsep way back to
>> 2008. At that time you'd pointed out a todo list for full rbac
>> separation support:
>>
>> 1. Kernel's recognition of role_transition rule for non process classes;
>>
>> 2. Role attribute support as in below rbacsep constrain:
>>
>> constrain { dir file ... } { getattr read write .... }
>> r1 == r2
>> or r1 == system_r
>> or r2 == object_r
>> or r1 == rbac_subj_role_file_exempt
>> or r2 == rbac_obj_role_file_exempt
>> or t1 == rbac_subj_type_file_exempt
>> or t2 == rbac_obj_type_file_exempt;
>>
>> 3. Add a new "role_change" rule and modify login/newrole program to
>> change controlling terminal's role according to that of user;
>>
>> 4. Add a new "role_member" rule for polyinstantiation support;
>>
>> 5. genhomedircon updated for role;
>> *6. Move the policy to initialize newcontext from security_compute_sid()
>> in kernel up to refpolicy, by introducing new rules such as(suggested by
>> Stephen, not directly related with rbacsep):
>>
>> role_default {process socket ...} fromsource;
>> type_default {process socket ...} fromsource;
>> role_default {file dir ...} fromtarget;
>> type_default {file dir ...} fromtarget;
>
> I don't remember this one.
>
>> Here are my comments and questions:
>>
>> As for 1, it has been done since we have added the class support to the
>> role_transition rule. Refpolicy could have whatever needed rules added
>> to transition the role of files/dirs from object_r;
>>
>> As for 2, it has been done too since we have added the role attribute
>> support;
>>
>> As for 3 & 4, it won't be difficult for us to add these two new rules,
>> but I have not understand clear yet the influence and meanings of the
>> role_change rule, could you explain it a bit more?
>
> Well we've had role_change rules since the ancient times. Its purpose
> is to inform userspace apps how to relabel a user's terminal when they
> change roles.
IIRC, the point with this one is that applications that use this (eg
login, newrole) would need to change the role on the terminal too.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
Hi Chris,
> >
> > As for 3 & 4, it won't be difficult for us to add these two new rules,
> > but I have not understand clear yet the influence and meanings of the
> > role_change rule, could you explain it a bit more?
>
> Well we've had role_change rules since the ancient times. Its purpose
> is to inform userspace apps how to relabel a user's terminal when they
> change roles.
>
Thanks, I understand role_change rule works like type_change rule to tell userspace app (pam_selinux.so, for example) how to relabel the role/type of the terminal when the user logins, but what benefit would we get by doing this? and what problem would we run into if we don't?
> > Also it seems that you had branched refpolicy to provide the rbac sep
> > constrain and collapse per-role templates such as xxx_sudo_t to
> > sudo_t(where can I get it?) but further run into type_transition
> > conflicts when sudo_t needs to transition back to user's domain:
> >
> > type_transition sudo_t shell_exec_t:process auditadm_t;
> > type_transition sudo_t shell_exec_t:process secadm_t;
> > type_transition sudo_t shell_exec_t:process staff_t;
> > type_transition sudo_t shell_exec_t:process sysadm_t;
> > type_transition sudo_t shell_exec_t:process user_t;
> >
> > You've mentioned since we can't make sudo application SELinux-aware due
> > to their vast differences, we would have to fall back on the per-role
> > template of xxx_sudo_t. (Actually this is the end of your rbacsep
> > effort, right?)
>
> Correct, thats where we stopped.
>
> > Would it be possible to tackle such condition by introducing a new
> > "type_transition_osid" rule? For example,
> >
> > type_transition_osid sudo_t shell_exec_t : process;
> >
> > And in security_compute_sid(), for AVTAB_TRANSITION rules we would
> > search for type_transition_osid rules aside from type_transition rules
> > for the process class. If a matching type_transition_osid rule is found,
> > then newcontext->type would be set to the type from tsec->osid.
> >
> > If it makes sense, then what else works may have been required aside
> > from it and the above todo list for full rbacsep support?
>
> We don't need to add anything special; we have the same problem with
> ubacsep, and solved it by retaining the per-role domains, eg. user_su_t,
> sysadm_sudo_t, etc.
>
> When we restart, it don't think it will be nearly as much work, since
> all of the collapsing was done for ubacsep.
>
So, you mean the per-role templates such as xxx_sudo_t and xxx_su_t would be retained along with specifying meaningful roles other than object_r, right?
And how do you feel about above "type_transition_osid" rule to collapse these per-role template? You mean it is not necessary for us to add such rule, since per-role templates are to be retained for rbacsep. But for ubacsep, per-role templates have been collapsed. I am a bit confused. How had we done that for ubacsep?
BTW, where can I get some reference for ubac and ubacsep?
Many thanks for your comments.
Best regards,
Harry
> --
> Chris PeBenito
> Tresys Technology, LLC
> http://www.tresys.com | oss.tresys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20110813/0aeb3a61/attachment.html
On 8/13/2011 4:39 AM, HarryCiao wrote:
> Hi Chris,
>
> > >
> > > As for 3 & 4, it won't be difficult for us to add these two new rules,
> > > but I have not understand clear yet the influence and meanings of the
> > > role_change rule, could you explain it a bit more?
> >
> > Well we've had role_change rules since the ancient times. Its purpose
> > is to inform userspace apps how to relabel a user's terminal when they
> > change roles.
> >
>
> Thanks, I understand role_change rule works like type_change rule to
> tell userspace app (pam_selinux.so, for example) how to relabel the
> role/type of the terminal when the user logins, but what benefit would
> we get by doing this? and what problem would we run into if we don't?
We would have to hard code the userspace app to always change the role
of the terminal. I'm on the fence as to if we really need this. On one
hand, in rbacsep, we always want the terminal role to be the same as the
role using it, so hard coding seems fine. But we all know how hard
coding behaviors can restrict flexibility.
> > > Also it seems that you had branched refpolicy to provide the rbac sep
> > > constrain and collapse per-role templates such as xxx_sudo_t to
> > > sudo_t(where can I get it?) but further run into type_tran sition
> > > conflicts when sudo_t needs to transition back to user's domain:
> > >
> > > type_transition sudo_t shell_exec_t:process auditadm_t;
> > > type_transition sudo_t shell_exec_t:process secadm_t;
> > > type_transition sudo_t shell_exec_t:process staff_t;
> > > type_transition sudo_t shell_exec_t:process sysadm_t;
> > > type_transition sudo_t shell_exec_t:process user_t;
> > >
> > > You've mentioned since we can't make sudo application SELinux-aware due
> > > to their vast differences, we would have to fall back on the per-role
> > > template of xxx_sudo_t. (Actually this is the end of your rbacsep
> > > effort, right?)
> >
> > Correct, thats where we stopped.
> >
> > > Would it be possible to tackle such condition by introducing a new
> > > "type_transition_osid" rule? For example,
> > >
> > > type_transition_osid sudo_t shell_exec_t : process;
> > >
> > > And in security_compute_sid(), for AVTAB_TRANSITION rules we would
> > > search for type_transition_osid rules aside from type_transition rules
> > > for the process class. If a matching type_transition_osid rule is
> found,
> > > then newcontext->type would be set to the type from tsec->osid.
> > >
> > > If it makes sense, then what else works may have been required aside
> > > from it and the above todo list for full rbacsep support?
> >
> > We don't need to add anything special; we have the same problem with
> > ubacsep, and solved it by retaining the per-role domains, eg. user_su_t,
> > sysadm_sudo_t, etc.
> >
> > When we restart, it don't think it will be nearly as much work, since
> > all of the collapsing was done for ubacsep.
> >
>
> So, you mean the per-role templates such as xxx_sudo_t and xxx_su_t
> would be retained along with specifying meanin gful roles other than
> object_r, right?
Right.
> And how do you feel about above "type_transition_osid" rule to collapse
> these per-role template? You mean it is not necessary for us to add such
> rule, since per-role templates are to be retained for rbacsep. But for
> ubacsep, per-role templates have been collapsed. I am a bit confused.
> How had we done that for ubacsep?
What I think you're missing is that this issue was solved in ubacsep.
So adding rbacsep back in after ubacsep has already been merged means
that the hard work of collapsing derived domains is already done, and I
don't foresee new problems with them. There are only a few domains that
have this issue; I don't think that we need to add more policy features
to completely collapse the templates.
> BTW, where can I get some reference for ubac and ubacsep?
There isn't a specific reference for it. It is almost all implemented
in the constraints in the ubac file.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com