On Wed, 31 Mar 2004 17:42, Aleksey Nogin <aleksey@xxxxxxxxx> wrote: > I would imagine sysadm_r can do a lot anyway, but just in case it is a > problem, here it is: > > % id > uid=500(aleksey) gid=500(aleksey) groups=500(aleksey) > context=aleksey:sysadm_r:sysadm_t > % rpm -q rpm --pipe id > uid=500(aleksey) gid=500(aleksey) groups=500(aleksey) > context=aleksey:sysadm_r:rpm_t > > Basically, the --pipe option to rpm seems to be giving sysadm_r full > access to sysadm_r:rpm_t By design sysadm_r can do everything, including disabling SE Linux. So being able to get rpm_t is no problem. In future we will provide an option to have a secadm_r role to perform security administration and a sysadm_r role that can only be used for basic sysadm tasks. Such a mode of operation will conflict with the --pipe command for rpm. When we implement that we will have to do something about the --pipe command, either disable it or have it cause a domain transition back to the calling domain. Another thing that will need to be done is to have multiple contexts for running rpm for different package signatures. This will probably require having the current rpm functionality split into two executables. This means that one can be used for parsing the command line, checking the signature, and running the --pipe operation. The other could do the real work. These are just some wild ideas. Hopefully Jeff will be available to give some better ones. -- http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/~russell/ My home page
