package configuration (for dpkg - rpm will have the same issues)

package configuration (for dpkg - rpm will have the same issues)

[Russell Coker]

When a package is installed in Debian scripts are run before and after the 
installation.  Among other things the pre-install script will often stop a 
daemon and the post-install script will start it again.

The problem comes when some scripts start daemons in such a fashion that the 
start script can't get standard input for run_init...

To solve this I was thinking of having an automatic transition from sysadm_t 
to dpkg_t when dpkg_exec_t programs are run.  Then there would be an 
automatic transition from dpkg_t when running initrc_exec_t binaries (all the 
start scripts) which stops run_init from needing a password.

What do you think of this idea?

If no-one comes up with a flaw in this idea then I'll implement it, and then 
it can be copied to an rpm script (both dpkg and rpm perform the same tasks 
using similar methods so their configuration should be very similar).

Also of course I'll set it up such that only dpkg can change it's own 
database etc (the usual boring things).

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Stephen Smalley]

On Thu, 14 Mar 2002, Russell Coker wrote:

> To solve this I was thinking of having an automatic transition from sysadm_t
> to dpkg_t when dpkg_exec_t programs are run.  Then there would be an
> automatic transition from dpkg_t when running initrc_exec_t binaries (all the
> start scripts) which stops run_init from needing a password.
>
> What do you think of this idea?

I'm not sure I understand.  run_init (or something similar) still needs to
be used when running the init scripts so that they are executed from the
proper security context.  run_init re-authenticates for the same reason as
newrole - to ensure that the user really wants to perform the transition,
as opposed to some malicious code run by the user.  If you eliminate the
user interaction for dpkg, how do you provide the same guarantee?  Or, if
you are willing to give up that guarantee, then why not just drop the
authentication out of your copy of run_init entirely.

--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Russell Coker]

On Fri, 15 Mar 2002 15:00, Stephen Smalley wrote:
> > To solve this I was thinking of having an automatic transition from
> > sysadm_t to dpkg_t when dpkg_exec_t programs are run.  Then there would
> > be an automatic transition from dpkg_t when running initrc_exec_t
> > binaries (all the start scripts) which stops run_init from needing a
> > password.
> >
> > What do you think of this idea?
>
> I'm not sure I understand.  run_init (or something similar) still needs to
> be used when running the init scripts so that they are executed from the
> proper security context.  run_init re-authenticates for the same reason as
> newrole - to ensure that the user really wants to perform the transition,
> as opposed to some malicious code run by the user.  If you eliminate the
> user interaction for dpkg, how do you provide the same guarantee?  Or, if
> you are willing to give up that guarantee, then why not just drop the
> authentication out of your copy of run_init entirely.

OK.  What if I make it the proceedure to use run_init to run dpkg or dselect 
for package installation or replacement?

The idea of dropping the authentication out of run_init or doing any major 
change to decrease the security of my setup is not something that I am 
prepared to consider.

My problem is that in the usual Debian package installation process the 
program dselect will run dpkg multiple times, each invocation may install 
multiple packages.  Each package installation may run multiple scripts that 
may end up starting daemons, in many cases the daemon start scripts will be 
run with standard input directed to be from /dev/null.  So if there is to be 
any authentication in the package installation process then it has to be 
before dselect is started.

Am I on the right track now?

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Stephen Smalley]

On Sat, 16 Mar 2002, Russell Coker wrote:

> OK.  What if I make it the proceedure to use run_init to run dpkg or dselect
> for package installation or replacement?
>
> The idea of dropping the authentication out of run_init or doing any major
> change to decrease the security of my setup is not something that I am
> prepared to consider.
>
> My problem is that in the usual Debian package installation process the
> program dselect will run dpkg multiple times, each invocation may install
> multiple packages.  Each package installation may run multiple scripts that
> may end up starting daemons, in many cases the daemon start scripts will be
> run with standard input directed to be from /dev/null.  So if there is to be
> any authentication in the package installation process then it has to be
> before dselect is started.
>
> Am I on the right track now?

The problem with this approach is that initrc_t isn't authorized to
install or replace packages on the system.  Hence, you only want to
transition to system_u:system_r:initrc_t for executing the init scripts,
not the installation.

--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Shaun Savage]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

HI

This is what i'm doing with rpm.
There is a rpm domain.
it takes a passwd to enter the rpm domain
the I have two options.
	disable checking
	play games with preinstall scripts and postinstall scripts

I choose disable checking

If the package has a nonstandard .te, that is installed into the
/etc/selinux/policy  directory and the policy is reloaded.

After install and before post install I configure the new files to the correct
attributes

I then restart checking

The problem that I came across is the are too many O-ZOT trying to force a
machine to auto update with checking on


an example is
~ any time a app is dependant upon it's execution upon a app that does'nt know
about it when the .te files were created.


Just some ideas
Shaun Savage

Russell Coker wrote:
| On Fri, 15 Mar 2002 15:00, Stephen Smalley wrote:
|
|>>To solve this I was thinking of having an automatic transition from
|>>sysadm_t to dpkg_t when dpkg_exec_t programs are run.  Then there would
|>>be an automatic transition from dpkg_t when running initrc_exec_t
|>>binaries (all the start scripts) which stops run_init from needing a
|>>password.
|>>
|>>What do you think of this idea?
|>
|>I'm not sure I understand.  run_init (or something similar) still needs to
|>be used when running the init scripts so that they are executed from the
|>proper security context.  run_init re-authenticates for the same reason as
|>newrole - to ensure that the user really wants to perform the transition,
|>as opposed to some malicious code run by the user.  If you eliminate the
|>user interaction for dpkg, how do you provide the same guarantee?  Or, if
|>you are willing to give up that guarantee, then why not just drop the
|>authentication out of your copy of run_init entirely.
|
|
| OK.  What if I make it the proceedure to use run_init to run dpkg or dselect
| for package installation or replacement?
|
| The idea of dropping the authentication out of run_init or doing any major
| change to decrease the security of my setup is not something that I am
| prepared to consider.
|
| My problem is that in the usual Debian package installation process the
| program dselect will run dpkg multiple times, each invocation may install
| multiple packages.  Each package installation may run multiple scripts that
| may end up starting daemons, in many cases the daemon start scripts will be
| run with standard input directed to be from /dev/null.  So if there is to be
| any authentication in the package installation process then it has to be
| before dselect is started.
|
| Am I on the right track now?
|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE8l9O3n6I06Opz+XURAozGAJ9UBCE7ityjP1h3FC8Cer1Ytc3bqQCgwYyG
e7Ftj0P5jCTHkSUhgH/oZ5w=
=U9j7
-----END PGP SIGNATURE-----


--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Russell Coker]

On Wed, 20 Mar 2002 01:11, Shaun Savage wrote:
> This is what i'm doing with rpm.
> There is a rpm domain.
> it takes a passwd to enter the rpm domain
> the I have two options.
> 	disable checking
> 	play games with preinstall scripts and postinstall scripts
>
> I choose disable checking

By "disable checking" do you mean using avc_toggle to turn off policy 
enforcement?

If you do that to avoid hackery with the preinstall/postinstall scripts then 
how do you ensure that daemons are running in the correct domains afterwards? 
Do you require a reboot of the system after the package installation?

> If the package has a nonstandard .te, that is installed into the
> /etc/selinux/policy  directory and the policy is reloaded.

This is not something that I plan to do.  I don't have enough confidance in 
package developers doing the right thing to allow automatic .te installation 
for MY system, and don't expect anyone who uses my packages to have any more 
faith.

I am not even confidant that I can write .te's that will avoid breaking 
things in some situations for some people.

So I plan to make it mandatory for the administrator to view the .te's.  I 
would like to make /etc/selinux not writable for dpkg_t.

> After install and before post install I configure the new files to the
> correct attributes

I was thinking that I will need to run setfiles before and after the 
postinstall script in case it does any file replacement.

> The problem that I came across is the are too many O-ZOT trying to force a
> machine to auto update with checking on

O-ZOT?

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.


--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Shaun Savage]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Russell Coker wrote:
| On Wed, 20 Mar 2002 01:11, Shaun Savage wrote:
|
|>This is what i'm doing with rpm.
|>There is a rpm domain.
|>it takes a passwd to enter the rpm domain
|>the I have two options.
|>
disable checking
|>
play games with preinstall scripts and postinstall scripts
|>
|>I choose disable checking
|
|
| By "disable checking" do you mean using avc_toggle to turn off policy
| enforcement?
|

Yes

| If you do that to avoid hackery with the preinstall/postinstall scripts then
| how do you ensure that daemons are running in the correct domains afterwards?
| Do you require a reboot of the system after the package installation?
|
|
I should/will be in single user mode.

even though single user mode is not a reeboot,  It does bring the system off line.


| This is not something that I plan to do.  I don't have enough confidance in
| package developers doing the right thing to allow automatic .te installation
| for MY system, and don't expect anyone who uses my packages to have any more
| faith.


Most people are not as smart as you. They don't understand how a .te is written.
I am thinking about a "verify" program that would check the validity of the new
.te before it is shipped.

|
| I am not even confidant that I can write .te's that will avoid breaking
| things in some situations for some people.
|

I can't ether

| So I plan to make it mandatory for the administrator to view the .te's.  I
| would like to make /etc/selinux not writable for dpkg_t.

would you have a wrapper domain that can write it?

The problem here I think is ease of use.  Only a really sharp admin would know
what going on even on a simple package. I can't explain the http package now ;-)
I know that most people would not look at the .te unless you forced them. and
even then only a very few would know what they are looking at.

In situations that REQUIRE super verified security, then the packages them self
will be "certified" for that platform and configuration. What "certified" means,
I don't know.

Most other users want the concept of security. They will believe you when you
say it is secure. (except me, I don't beleive it when I say it:) If the average
admin is to use SELinux then it needs to be as easy as a Redhat or debian install.

Say MSWindows is 75% secure, plain linux offers 99% secure, then SELinux is
might be 99.999% secure. but if the admin is harder then MSWindows, the average
user will not use it.
I would personally, want it 99.99% and as easy as M$. to get people to use it.
It least they are USING Linux, with better security.
If 99.9999% is needed then the paper work would kill the developer.



|
| I was thinking that I will need to run setfiles before and after the
| postinstall script in case it does any file replacement.
|
good idea, the thing I have done has not needed it, but I will assume there will
be thoses that do.

|
|
| O-ZOT?
I don't swear

|

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE8mII4n6I06Opz+XURAv5+AKCk+QnYSykE4Vy9sViLrW4GEyujzgCeMPQ/
7fWYeWFu1wzxKghsp5ArjRk=
=TAj+
-----END PGP SIGNATURE-----


--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Russell Coker]

On Wed, 20 Mar 2002 13:36, Shaun Savage wrote:
> | If you do that to avoid hackery with the preinstall/postinstall scripts
> | then how do you ensure that daemons are running in the correct domains
> | afterwards? Do you require a reboot of the system after the package
> | installation?
>
> I should/will be in single user mode.
>
> even though single user mode is not a reeboot,  It does bring the system
> off line.

Single user mode is effectively a reboot for users of the system.

> | This is not something that I plan to do.  I don't have enough confidance
> | in package developers doing the right thing to allow automatic .te
> | installation for MY system, and don't expect anyone who uses my packages
> | to have any more faith.
>
> Most people are not as smart as you. They don't understand how a .te is
> written. I am thinking about a "verify" program that would check the
> validity of the new .te before it is shipped.

Check in what sense?  Checking for syntax errors should be easy enough, 
checking for dependencies with other .te's without actually compiling it will 
be difficult, checking for stupid mistakes should be possible, but checking 
for subtle mistakes or malicious omissions will be impossible.

> | So I plan to make it mandatory for the administrator to view the .te's. 
> | I would like to make /etc/selinux not writable for dpkg_t.
>
> would you have a wrapper domain that can write it?

I was thinking of having the usual sysadm_t domain write it.  But you may be 
right, it might make sense to have a special domain to do it.

> The problem here I think is ease of use.  Only a really sharp admin would
> know what going on even on a simple package. I can't explain the http
> package now ;-) I know that most people would not look at the .te unless
> you forced them. and even then only a very few would know what they are
> looking at.

That's OK, if they want to just blindly copy the files then that's their 
choice.

> In situations that REQUIRE super verified security, then the packages them
> self will be "certified" for that platform and configuration. What
> "certified" means, I don't know.

You still can't do pre-packaged .te's that are complete and fully 
restrictive.  Consider the issue of which source of password data to use 
through nss.  Consider the issue of which Apache modules are loaded.  These 
things can require substantial and subtle changes to many settings.

> Most other users want the concept of security. They will believe you when
> you say it is secure. (except me, I don't beleive it when I say it:) If the
> average admin is to use SELinux then it needs to be as easy as a Redhat or
> debian install.

The average admin can't properly deal with standard unix permissions.  The 
average admin can't compile their own kernel.  Is SE Linux ever going to be 
for the average admin?

> | I was thinking that I will need to run setfiles before and after the
> | postinstall script in case it does any file replacement.
>
> good idea, the thing I have done has not needed it, but I will assume there
> will be thoses that do.

Another thing is that I need to patch setfiles to take a list of file names 
on standard input.  Checking the entire file system after replacing a single 
package does not make sense.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Shaun Savage]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



|
|
| Single user mode is effectively a reboot for users of the system.
|
Yes

|
| Check in what sense?  Checking for syntax errors should be easy enough,
| checking for dependencies with other .te's without actually compiling it will
| be difficult, checking for stupid mistakes should be possible, but checking
| for subtle mistakes or malicious omissions will be impossible.
|

I look at the policy as a giant state machine.  The checking could/should be
done off line.  By using the same concepts used in VLSI design, a software
program could look for nasties. Sounds like a great thesis :) Any one want to
send me to school again? I have work on it some and have a few things worked out
but  it would be a two year effort to have something that would get the  test
coverage needed.

|
| I was thinking of having the usual sysadm_t domain write it.  But you may be
| right, it might make sense to have a special domain to do it.
|
|
|>In situations that REQUIRE super verified security, then the packages them
|>self will be "certified" for that platform and configuration. What
|>"certified" means, I don't know.
|
|
| You still can't do pre-packaged .te's that are complete and fully
| restrictive.  Consider the issue of which source of password data to use
| through nss.  Consider the issue of which Apache modules are loaded.  These
| things can require substantial and subtle changes to many settings.
|

I agree, but what I am saying is There can be a standard install and standard
packages. The The standard is not fully restrictive. you try for 99.99% not
99.999% It will be a subset of a full system. If a/the company wants the 99.999%
security and flexability the need to hire us to do it.
|
|
| The average admin can't properly deal with standard unix permissions.  The
| average admin can't compile their own kernel.  Is SE Linux ever going to be
| for the average admin?
|

Yes, I would like a distro that works out the the box. all the admin does is add
users, create virtual web sites. .... They don't mess with the system.  The
packages are tested and verifed before it get to the sysadmin.

I would like to see SELinux in the schools, hospitals, police/fire stations, in
~ dept. of fish and wildlife offices.  But that the 99.99%, where Mr Msadmin can
just click a button the system drops to admin mode, drag the new package to the
~ install box and its done. World peace, and a chicken in every pot. :)


|
| Another thing is that I need to patch setfiles to take a list of file names
| on standard input.  Checking the entire file system after replacing a single
| package does not make sense.
|

Yes


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE8mJwbn6I06Opz+XURAq9bAJ9gRQaxvsBqZHN7/cItFWTguPH+wwCgtyZW
bzX/kps3A34n99HpRIgbONo=
=dEHp
-----END PGP SIGNATURE-----


--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Russell Coker]

On Wed, 20 Mar 2002 15:26, Shaun Savage wrote:
> | Check in what sense?  Checking for syntax errors should be easy enough,
> | checking for dependencies with other .te's without actually compiling it
> | will be difficult, checking for stupid mistakes should be possible, but
> | checking for subtle mistakes or malicious omissions will be impossible.
>
> I look at the policy as a giant state machine.  The checking could/should
> be done off line.  By using the same concepts used in VLSI design, a
> software program could look for nasties. Sounds like a great thesis :) Any
> one want to send me to school again? I have work on it some and have a few
> things worked out but  it would be a two year effort to have something that
> would get the  test coverage needed.

I recall a message from an IBMer some time ago about some work in that 
general direction.

> | The average admin can't properly deal with standard unix permissions. 
> | The average admin can't compile their own kernel.  Is SE Linux ever going
> | to be for the average admin?
>
> Yes, I would like a distro that works out the the box. all the admin does
> is add users, create virtual web sites. .... They don't mess with the
> system.  The packages are tested and verifed before it get to the sysadmin.
>
> I would like to see SELinux in the schools, hospitals, police/fire
> stations, in ~ dept. of fish and wildlife offices.

What is needed for that is a set of "teacher machine" policy files for SE 
Linux, a set of "student workstation" policy files, a set of "student 
time-share machine" policy files and a set of Police policy files.  All these 
would have to be quite different (although teacher machines and Police 
machines would have similar requirements).

>  But that the 99.99%,
> where Mr Msadmin can just click a button the system drops to admin mode,
> drag the new package to the ~ install box and its done. World peace, and a
> chicken in every pot. :)

That requires huge amounts of work writing policy files.  Some of my policy 
files have taken me more than a day's work.  I am getting better at it now, 
but I've still got to do Postfix which will be really painful.

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Shaun Savage]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



|>
|>I would like to see SELinux in the schools, hospitals, police/fire
|>stations, in ~ dept. of fish and wildlife offices.
|
|
| What is needed for that is a set of "teacher machine" policy files for SE
| Linux, a set of "student workstation" policy files, a set of "student
| time-share machine" policy files and a set of Police policy files.  All these
| would have to be quite different (although teacher machines and Police
| machines would have similar requirements).
|
|

Yes, each one would have a setup but there are common policies.

|
|
| That requires huge amounts of work writing policy files.  Some of my policy
| files have taken me more than a day's work.  I am getting better at it now,
| but I've still got to do Postfix which will be really painful.
|

I am trying to secure courier mail system, What a pain.

Shaun
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE8mLK9n6I06Opz+XURAmq8AJ9qe7Q+bbxl7y1O5CuzrVgTg8zr2gCglQzc
Jh7pib672OpJV5RlUjpCjug=
=WD2a
-----END PGP SIGNATURE-----


--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Russell Coker]

[-- Attachment #1: Type: text/plain, Size: 1021 bytes --]

On Wed, 20 Mar 2002 17:03, Shaun Savage wrote:
> I am trying to secure courier mail system, What a pain.

I've attached the .te file for my work in progress, below are the 
file_contexts entries.  I've only got the authdaemon going so far, I am only 
aiming to get the POP and IMAP servers working.

What have you got so far?

/etc/courier/(|/.*)             system_u:object_r:etc_courier_t
/usr/lib/courier(|/.*)          system_u:object_r:etc_courier_t
/usr/lib/courier/authlib/.*     system_u:object_r:courier_exec_t
/usr/lib/courier/courier/.*     system_u:object_r:courier_exec_t
/usr/sbin/courier.*             system_u:object_r:courier_exec_t
/var/run/courier.*              system_u:object_r:courier_var_run_t

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

[-- Attachment #2: courier.te --]
[-- Type: text/plain, Size: 2234 bytes --]

#
# Author:  Russell Coker <russell@coker.com.au>
#

#################################
#
# Rules for the courier_t domain.
#
# courier_exec_t is the type of the courier executables.
#
type courier_t, domain, privlog;
type courier_exec_t, file_type, sysadmfile, exec_type;
type etc_courier_t, file_type, sysadmfile;

role system_r types courier_t;

allow courier_t init_t:process sigchld;

# Type for files created during execution of courier.
type courier_var_run_t, file_type, sysadmfile;
file_type_auto_trans(courier_t, var_run_t, courier_var_run_t)

# allow it to read it's config files etc
allow courier_t { etc_courier_t var_t }:dir r_dir_perms;
allow courier_t etc_courier_t:file r_file_perms;
allow courier_t etc_t:dir r_dir_perms;
allow courier_t etc_t:{ file lnk_file } r_file_perms;

# execute scripts etc
allow courier_t { bin_t courier_exec_t }:file rx_file_perms;
allow courier_t bin_t:dir r_dir_perms;
allow courier_t fs_t:filesystem getattr;

# set process group and allow permissions over-ride
allow courier_t courier_t:process { setpgid fork };
allow courier_t courier_t:capability dac_override;

# Inherit and use descriptors from init.
allow courier_t init_t:fd inherit_fd_perms;
allow courier_t { init_t courier_t }:process sigchld;

# Use the network.
can_network(courier_t)
allow courier_t courier_t:fifo_file { read write getattr };
allow courier_t courier_t:unix_stream_socket create_stream_socket_perms;
allow courier_t courier_t:unix_dgram_socket create_socket_perms;

allow courier_t null_device_t:chr_file rw_file_perms;

# Use capabilities
#allow courier_t courier_t:capability { net_raw };
#allow courier_t courier_t:process { setsched signal };

# allow it to log to /dev/tty
allow courier_t devtty_t:chr_file rw_file_perms;

domain_auto_trans(initrc_t, courier_exec_t, courier_t)

allow courier_t { usr_t etc_runtime_t }:file r_file_perms;
allow courier_t usr_t:dir r_dir_perms;
allow courier_t root_t:dir r_dir_perms;
can_exec(courier_t, courier_exec_t)
can_exec(courier_t, bin_t)
uses_shlib(courier_t)

allow courier_t proc_t:dir r_dir_perms;
allow courier_t proc_t:file r_file_perms;

# do the actual work
allow courier_t user_home_t:dir rw_dir_perms;
allow courier_t user_home_t:file r_file_perms;

Re: package configuration (for dpkg - rpm will have the same issues)

[Stephen Smalley]

On Wed, 20 Mar 2002, Russell Coker wrote:

> Another thing is that I need to patch setfiles to take a list of file names
> on standard input.  Checking the entire file system after replacing a single
> package does not make sense.

I'd suggest using chcon or chsid for that purpose.  Just provide a script
with each package that runs chcon/chsid with the appropriate context for
each file installed by the package.  I would also recommend updating the
setfiles configuration for any future 'make relabel' commands, but not
necessarily running it each time.

--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Russell Coker]

On Wed, 20 Mar 2002 17:47, Stephen Smalley wrote:
> On Wed, 20 Mar 2002, Russell Coker wrote:
> > Another thing is that I need to patch setfiles to take a list of file
> > names on standard input.  Checking the entire file system after replacing
> > a single package does not make sense.
>
> I'd suggest using chcon or chsid for that purpose.  Just provide a script
> with each package that runs chcon/chsid with the appropriate context for
> each file installed by the package.  I would also recommend updating the
> setfiles configuration for any future 'make relabel' commands, but not
> necessarily running it each time.

I don't like that idea at all.  Having two sources for the same data is 
guaranteed to cause you trouble.

What benefit is there to using chsid instead of a hacked setfiles?

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Stephen Smalley]

On Wed, 20 Mar 2002, Russell Coker wrote:

> I don't like that idea at all.  Having two sources for the same data is
> guaranteed to cause you trouble.
>
> What benefit is there to using chsid instead of a hacked setfiles?

Perhaps there isn't any.

setfiles was designed to set the security contexts for the entire
filesystem in accordance with an overall configuration.  The intent was to
only use it during installation to initialize the mappings and optionally
later to reset the mappings to the initial state again.  You might also
use it to implement wholesale changes to the mappings due to a major
policy change.

Once you've initialized the mappings and are running a SELinux kernel, the
mappings are maintained dynamically by the kernel to reflect create,
delete, and relabel (chsid) operations.  At that point, you can set the
security context for particular files in a similar manner to the Unix
ownership and mode via chcon or the modified file utilities.  Even apart
from chsid operations, there will be some drift from the original setfiles
configuration as new files are created, particularly when file type
transition rules are defined that deviate from the parent directory's
type.

When a new package is installed on a system running SELinux, I expected
chcon or the modified file utilities to be used to set the security
context appropriately for its files in a similar manner to the use
of chown/chmod or the existing file utilities for setting the Unix
attributes.  But it also seems necessary to update the setfiles
configuration for future installations, resets, or major policy changes.
So perhaps a hacked setfiles is a good idea.

--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Dale Amon]

On Wed, Mar 20, 2002 at 12:48:40PM -0500, Stephen Smalley wrote:
> When a new package is installed on a system running SELinux, I expected
> chcon or the modified file utilities to be used to set the security
> context appropriately for its files in a similar manner to the use
> of chown/chmod or the existing file utilities for setting the Unix
> attributes.  But it also seems necessary to update the setfiles
> configuration for future installations, resets, or major policy changes.
> So perhaps a hacked setfiles is a good idea.

Perhaps a 'setfiles --dump > file_contexts' capability is in order?


--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Stephen Smalley]

On Fri, 22 Mar 2002, Dale Amon wrote:

> Perhaps a 'setfiles --dump > file_contexts' capability is in order?

Yes, automatically updating the file contexts configuration based on the
filesystem state would be useful, although it may not be
completely straightforward.  If you simply want an exhaustive listing of
files and their contexts, you can use the modified find program.  But
the file contexts configuration is much more concise, as it uses
pathname regular expressions.  To update the file contexts configuration,
you would likely want setfiles to read an existing configuration and only
output entries for files whose security contexts are not consistent with
the existing configuration.  This isn't that different from using
setfiles -vn to show what files would be relabeled without actually
performing any relabeling, except that the output format would be
different.  Ideally, setfiles would also perform some degree of
intelligent filtering, e.g. coalescing new entries that can be captured by
a single pathname regular expression.

--
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.

Re: package configuration (for dpkg - rpm will have the same issues)

[Russell Coker]

On Fri, 22 Mar 2002 15:08, Dale Amon wrote:
> On Wed, Mar 20, 2002 at 12:48:40PM -0500, Stephen Smalley wrote:
> > When a new package is installed on a system running SELinux, I expected
> > chcon or the modified file utilities to be used to set the security
> > context appropriately for its files in a similar manner to the use
> > of chown/chmod or the existing file utilities for setting the Unix
> > attributes.  But it also seems necessary to update the setfiles
> > configuration for future installations, resets, or major policy changes.
> > So perhaps a hacked setfiles is a good idea.
>
> Perhaps a 'setfiles --dump > file_contexts' capability is in order?

Making that generate a list suitable for setsid or chcon would be easy.  
Making it generate something that approximates the original file_contexts 
would be very difficult.  Also there are lots of files that won't be on a 
typical system which are in file_contexts, how would a setfiles --dump handle 
them?

-- 
If you send email to me or to a mailing list that I use which has >4 lines
of legalistic junk at the end then you are specifically authorizing me to do
whatever I wish with the message and all other messages from your domain, by
posting the message you agree that your long legalistic sig is void.

--
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.