首先，编辑refpolicy-xxxxx/policy/下的users文件, 仿照sysadm添加如下语句：
gen_user(secadm_u, user, secadm_r, s0, s0 - mls_systemhigh, mcs_allcats)
gen_user(auditadm_u, user, auditadm_r, s0, s0 - mls_systemhigh, mcs_allcats)
注：users文件是debian的官方策略源码包里的，对应rpm的官方策略源码包里的三个文件：users-minimum、users-mls和users-targeted。
然后，在kernel.te中添加role secadm_r; 和role auditadm_r;来申明角色:

这是因为如果不申明，编译users文件的时候就会报未知角色的错误:

到这一步，debian版的源码包已经可以编译通过了，但是rpm版的源码包编译却失败了，错误log如下：

我的rpm包是基于openSUSE用Open Build Service (OBS) 构建，通过osc build编译。编译环境比debian的复杂许多
从截图可以看出来，编译用到了/usr/lib/python3.6/site-package/sepolicy/manpage.py的一个python脚本，此处报错就是这个脚本里报错了，故，打开脚本分析报错点，根据打印，定位到1079行和1071行：

分别搜索self.domainname和self.role_allows的定义，定位到ManPage类，刚好就是错误打印中调用的（本层第一个图片的第一个红框）:

self.domainname和self.role_allows的赋值都在__init__方法中:

创建对象时的初始化入参domain（报错log图片的第一个红框里）怎么也找不到在哪定义的，不过大概可以推测是将我在users中新增的两句gen_user后面的xxx_u去掉_u得到的:

因为我将auditadm_u的那句删除后，报错打印就从auditadm_r变成secadm_r了。
所以，self.role_allows的下标(python中叫字典的key)就是xxx和_r的拼接。因为我们新增了gen_user(secadm_u....和gen_user(auditadm_u....所以，就报了'auditadm_r'的KeyError。（为什么没报secadm_r的错呢？我猜测是先编译的后一句，后一句报错后，编译就停止了）
故，问题就变成了，self.role_allows这个对象属性为什么没有auditadm_r这个key对应的字典项。分析3楼最后一个图片中的黄色方框，可知self.role_allows实际是由sepolicy模块的get_all_role_allows()函数获得，在/usr/lib/python3.6/site-packages/sepolicy目录下grep get_all_role_allows搜索，在__init__.py文件找到定义：

果然，role_allows为python中的字典类型，key是由src获得，而src是由setools模块的RBACRuleQuery方法通过[ALLOW]的ruletype获得！我没找到RBACRuleQuery的定义，但是可以推测，这个函数应该是遍历所有selinux的allow策略！而这个函数的名字叫做RBACRule，那肯定就是跟角色相关，并且从role_allows这个字典变量的名字分析，应该是allow role1 role2这样的主客体为角色的allow策略！然后再分析源码，发现三大管理员里，确实只有sysadm.te中调用了staff_role_change(sysadm_r)。而auditadm和secadm都没有。staff_role_change接口定义如下:

所以官方的源码里虽然有gen_user(sysadm_u.....这样的策略，但是依然能编过。
于是，我在secadm.te和auditadm.te中也分别加上staff_role_change(secadm_r)和staff_role_change(auditadm_r)后测试，编译通过！
为什么debian没有这样的问题？因为debian的编译环境比较简单，没有用类似的python脚本！

楼主是出去什么心态和目的学习selinux的呢？我刚刚也接触到了这个东西，学了些基础概念和命令。有必要深入去学吗，请指教