I am considering how to make SE Linux integrate smoothly with Debian
regarding the startup of daemons.
Requiring everyone to change all their init scripts is out of the question of course.
One thing I have played with is setting the security contexts so that the daemon automatically changes to the correct domain on startup from the sysadm_t domain such as the following (and also a minor matching change to rbac to make it allow root:sysadm_r:sshd_t):
domain_auto_trans(sysadm_t , sshd_exec_t, sshd_t)
This is minorly ugly, involves more rules than I'd like, but has the benefit that running "sshd" at the command line gets the same result as "/etc/init.d/ssh start".
The other option is to divert /sbin/start-stop-daemon which is used by Debian for starting most (should be all) daemons. Then my replacement script would call run_init to run the real start-stop-daemon.
Any comments on the relative merits of these two schemes?
I realise that the recommended way is probably run_init (it was written for a reason), but how bad an idea is it to not use it?
-- 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/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- You have received this message because you are subscribed to the selinux 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.From: Manoj Srivastava <manoj.srivastava_at_stdc.com>
>>"Russell" == Russell Coker <russell@coker.com.au> writes:
Russell> One thing I have played with is setting the security Russell> contexts so that the daemon automatically changes to the Russell> correct domain on startup from the sysadm_t domain such as Russell> the following (and also a minor matching change to rbac to Russell> make it allow root:sysadm_r:sshd_t):
Russell> domain_auto_trans(sysadm_t , sshd_exec_t, sshd_t)
Russell> This is minorly ugly, involves more rules than I'd like, but Russell> has the benefit that running "sshd" at the command line gets Russell> the same result as "/etc/init.d/ssh start". Russell> The other option is to divert /sbin/start-stop-daemon which Russell> is used by Debian for starting most (should be all) daemons.Russell> Then my replacement script would call run_init to run the Russell> real start-stop-daemon.
But you lose the option to start sshd on the command line, don't you?
Russell> Any comments on the relative merits of these two schemes?
Putting on my Debian hat, I'd prefer the former, all else being the same. I'd also like to investigate the possibility of packages providing the recommended additions to policy, which can be used by the policy admin as a guide to what rules may be needed to utilize a package to the fullest capacity (I would not, of course, skip the human oversight step and automate the process).
manoj
-- A Los Angeles judge ruled that "a citizen may snore with immunity in his own home, even though he may be in possession of unusual and exceptional ability in that particular field." Manoj Srivastava <manoj.srivastava@stdc.com> <srivasta@acm.org> 1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- You have received this message because you are subscribed to the selinux 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.From: Russell Coker <russell_at_coker.com.au>
On Sun, 20 Jan 2002 07:49, Manoj Srivastava wrote:
> >>"Russell" == Russell Coker <russell@coker.com.au> writes:
>
> Russell> One thing I have played with is setting the security
> Russell> contexts so that the daemon automatically changes to the
> Russell> correct domain on startup from the sysadm_t domain such as
> Russell> the following (and also a minor matching change to rbac to
> Russell> make it allow root:sysadm_r:sshd_t):
>
> Russell> domain_auto_trans(sysadm_t , sshd_exec_t, sshd_t)
>
> Russell> This is minorly ugly, involves more rules than I'd like, but
> Russell> has the benefit that running "sshd" at the command line gets
> Russell> the same result as "/etc/init.d/ssh start".
>
> Russell> The other option is to divert /sbin/start-stop-daemon which
> Russell> is used by Debian for starting most (should be all) daemons.
> Russell> Then my replacement script would call run_init to run the
> Russell> real start-stop-daemon.
>
> But you lose the option to start sshd on the command line,
> don't you?
You lose the option to type "sshd" to start it, but you don't lose the option to type "/etc/init.d/ssh start".
> Russell> Any comments on the relative merits of these two schemes?
>
> Putting on my Debian hat, I'd prefer the former, all else
> being the same. I'd also like to investigate the possibility of
> packages providing the recommended additions to policy, which can be
> used by the policy admin as a guide to what rules may be needed to
> utilize a package to the fullest capacity (I would not, of course,
> skip the human oversight step and automate the process).
Good point.
I think that we need a program to modify devfs_contexts and file_contexts and run chsid (for devfs_contexts) and give the option of either relabeling or running chsid for changes to file_contexts. Also we need some sort of program that operates in a similar fashion to useradd for the rbac file.
All of this needs to ask sane questions of the user.
PS We'll have to use chsid not chcon because chcon isn't in the base package.
-- 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/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page -- You have received this message because you are subscribed to the selinux 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.From: Stephen Smalley <sds_at_tislabs.com>
On Sat, 19 Jan 2002, Russell Coker wrote:
> I am considering how to make SE Linux integrate smoothly with Debian
> regarding the startup of daemons.
>
> Requiring everyone to change all their init scripts is out of the question of
> course.
>
> One thing I have played with is setting the security contexts so that the
> daemon automatically changes to the correct domain on startup from the
> sysadm_t domain such as the following (and also a minor matching change to
> rbac to make it allow root:sysadm_r:sshd_t):
>
> domain_auto_trans(sysadm_t , sshd_exec_t, sshd_t)
>
> This is minorly ugly, involves more rules than I'd like, but has the benefit
> that running "sshd" at the command line gets the same result as
> "/etc/init.d/ssh start".
>
> The other option is to divert /sbin/start-stop-daemon which is used by Debian
> for starting most (should be all) daemons. Then my replacement script would
> call run_init to run the real start-stop-daemon.
>
> Any comments on the relative merits of these two schemes?
>
> I realise that the recommended way is probably run_init (it was written for a
> reason), but how bad an idea is it to not use it?
Obviously, we would recommend using run_init. The other scheme has the
following limitations:
1) It only sets the domain of the daemon process, not the user identity or
role, whereas run_init ensures that the complete security context is set
correctly,
2) It doesn't provide any safeguard to ensure that the administrator truly
wants to start or restart a system process (as opposed to some malicious
code run by the administrator), whereas run_init requires the
administrator to re-authenticate to confirm the action,
3) It requires significant duplication of rules between the initrc_t
domain and the sysadm_t domain.
-- Stephen D. Smalley, NAI Labs ssmalley@nai.com -- You have received this message because you are subscribed to the selinux 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.
This archive was generated by hypermail 2.2.0 on Wed 11 Jun 2008 - 08:10:54 EDT