Security Enhanced Linux
What's New
Frequently Asked Questions
Background
Documents
License
Download
Participating
Mail List
Archives
Remaining Work
Contributors
Related Work
Press Releases
Information Assurance Research
NIARL In-house Research Areas
Mathematical Sciences Program
Sabbaticals
Computer & Information Sciences Research
Technology Transfer
Advanced Computing
Advanced Mathematics
Communications & Networking
Information Processing
Microelectronics
Other Technologies
Technology Fact Sheets
Publications
Related Links
|
SELinux Mailing List
subject: package configuration (for dpkg - rpm will have the same issues) Date: Thu, 14 Mar 2002 18:28:22 +0100
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).
--
-- subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Fri, 15 Mar 2002 09:00:32 -0500 (EST)
On Thu, 14 Mar 2002, Russell Coker wrote:
> To solve this I was thinking of having an automatic transition from sysadm_t 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.From: Russell Coker <russell_at_coker.com.au> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Sat, 16 Mar 2002 00:19:22 +0100
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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Mon, 18 Mar 2002 16:38:31 -0500 (EST)
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 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.From: Shaun Savage <savages_at_pcez.com> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Tue, 19 Mar 2002 16:11:37 -0800
HI
This is what i'm doing with rpm.
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
Just some ideas
Russell Coker wrote:
-----BEGIN PGP SIGNATURE-----
iD8DBQE8l9O3n6I06Opz+XURAozGAJ9UBCE7ityjP1h3FC8Cer1Ytc3bqQCgwYyG
e7Ftj0P5jCTHkSUhgH/oZ5w=
-- 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> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Wed, 20 Mar 2002 10:41:08 +0100
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 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 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 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.From: Shaun Savage <savages_at_pcez.com> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Wed, 20 Mar 2002 04:36:09 -0800
Russell Coker wrote:
Yes
| If you do that to avoid hackery with the preinstall/postinstall scripts then 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 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 can't ether
| So I plan to make it mandatory for the administrator to view the .te's. I 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.
|
|
|
-----BEGIN PGP SIGNATURE-----
iD8DBQE8mII4n6I06Opz+XURAv5+AKCk+QnYSykE4Vy9sViLrW4GEyujzgCeMPQ/
7fWYeWFu1wzxKghsp5ArjRk=
-- 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> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Wed, 20 Mar 2002 14:35:13 +0100
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 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 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 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 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 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 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.From: Shaun Savage <savages_at_pcez.com> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Wed, 20 Mar 2002 06:26:37 -0800
|
| 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 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.
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. :)
| Yes
-----BEGIN PGP SIGNATURE-----
iD8DBQE8mJwbn6I06Opz+XURAq9bAJ9gRQaxvsBqZHN7/cItFWTguPH+wwCgtyZW
bzX/kps3A34n99HpRIgbONo=
-- 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> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Wed, 20 Mar 2002 16:31:29 +0100
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. 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%, 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.From: Shaun Savage <savages_at_pcez.com> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Wed, 20 Mar 2002 08:03:11 -0800
|> Yes, each one would have a setup but there are common policies.
| I am trying to secure courier mail system, What a pain.
Shaun
iD8DBQE8mLK9n6I06Opz+XURAmq8AJ9qe7Q+bbxl7y1O5CuzrVgTg8zr2gCglQzc
Jh7pib672OpJV5RlUjpCjug=
-- 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> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Wed, 20 Mar 2002 17:43:25 +0100
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 -- 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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Wed, 20 Mar 2002 11:47:30 -0500 (EST)
On Wed, 20 Mar 2002, Russell Coker wrote:
> Another thing is that I need to patch setfiles to take a list of file names 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.From: Russell Coker <russell_at_coker.com.au> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Wed, 20 Mar 2002 18:12:16 +0100
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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Wed, 20 Mar 2002 12:48:40 -0500 (EST)
On Wed, 20 Mar 2002, Russell Coker wrote:
> I don't like that idea at all. Having two sources for the same data is 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.From: Dale Amon <amon_at_vnl.com> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Fri, 22 Mar 2002 14:08:33 +0000
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.From: Stephen Smalley <sds_at_tislabs.com> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Fri, 22 Mar 2002 09:44:52 -0500 (EST)
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.From: Russell Coker <russell_at_coker.com.au> subject: Re: package configuration (for dpkg - rpm will have the same issues) Date: Fri, 22 Mar 2002 15:54:45 +0100
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.
|
|
Date Posted: Jan 15, 2009 | Last Modified: Jan 15, 2009 | Last Reviewed: Jan 15, 2009 |