[Fwd: Re: avc_toggle and avc_enforcing]

[Fwd: Re: avc_toggle and avc_enforcing]

[Daniel J Walsh]

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



[-- Attachment #2: Re: avc_toggle and avc_enforcing --]
[-- Type: message/rfc822, Size: 7312 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 2518 bytes --]

Kerry Thompson wrote:

>Speaking of which, I'd like to assemble a quick list of userland ( or more
>accurately, adminland ) changes between the current release and the
>previous non-/selinux release to update the documentation I've got, like
>the U-FAQ. The ones I've noticed so far :
>
>- avc_enforcing, avc_toggle replaced by /selinux/enforcing
>- id command requires -c to display context
>  
>
This has been converted to -Z in latest patches, for consistency.

>- ps command uses -Z to display context
>- initrd now mandatory
>  
>
We are working to remove this requirement.

>- selinux kernel boot option
>- multiple changes to installation procedure
>  
>
>- SRPMs added to installation image
>- new tools added ( Tresys tools, star )
>- binary RPMs available ( thanks Daniel )
>
>  
>
Your welcome.

>I've looked into the ChangeLog files, but there really isn't much info
>there, so I'd like to hear of any other changes that have been made which
>need to be documented.
>
>  
>
We are working to eliminate root assumptions in the OS and replace them 
with ones based on
security contexts.  So config tools should be prompting for your 
password instead of root password. 

One goal of userland changes is that the average user should not have to 
know that he is running
on a SELinux machine.  A system administrator should be able to manage 
the machine with limited knowlege of the way policy works.

>I'm still working on getting my test system up to the new 2.4 and 2.6,
>unfortunately I rendered it unbootable last night so it will take a little
>longer than expected ( note to self : make sure kernel can build an initrd
>before removing /boot/initrd* ).
>
>Kerry
>
>
>Stephen Smalley said:
>  
>
>>On Tue, 2003-10-14 at 08:15, Carlos Anísio Monteiro wrote:
>>    
>>
>>>Please, where I find the commands: avc_toggle and avc_enforcing. What
>>>are it the packages where it are?
>>>      
>>>
>>They no longer exist as programs.  With the new SELinux API, you can
>>simply 'cat /selinux/enforce' to see the current enforcing value,
>>'echo 1 > /selinux/enforce' to switch into enforcing mode, and
>>'echo  > /selinux/enforce' to switch into permissive mode (if permitted
>>by the policy).
>>
>>--
>>Stephen Smalley <sds@epoch.ncsc.mil>
>>National Security Agency
>>    
>>
>
>
>--
>This message was distributed to subscribers of the selinux mailing 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.
>  
>

[-- Attachment #2.1.2: Type: text/html, Size: 3819 bytes --]

Re: [Fwd: Re: avc_toggle and avc_enforcing]

[Russell Coker]

On Thu, 16 Oct 2003 23:31, Daniel J Walsh wrote:
> on a SELinux machine.  A system administrator should be able to manage
> the machine with limited knowlege of the way policy works.

I guess that the next thing we want is per-role instantiations for run_init.  
So for example we could have:
full_user_role(dba)
run_program(dba_t, dba_r, dba, initrc_exec_t, postgresql_t)
allow run_dba_t self:capability setuid;

Then the Database administrator could login as user:dba_r:dba_t to run all 
unix programs, and they could have a SUID root program with type 
run_dba_exec_t which would run /etc/init.d/postgresql with specified 
parameters.  That combined with a few rules relating to file access would 
give them full control over the database server without granting any access 
to the rest of the system.

NB It's quite important that such uses of run_program which have something 
other than sysadm_t as the first parameter do not have initrc_t as the last 
parameter!  It is very important that we restrict initrc_t.

Also it's very important that the program which has run_dba_exec_t is a very 
simple program that sets it's UID, sets the execute context, and executes the 
script.  As it has privrole we want to be very sure that it does not do the 
wrong thing.  Privrole is necessary as it has to start the daemon as 
system_r.


I've been meaning to write policy for this for some time, but have lacked 
suitable opportunities for testing.  The machines I've been involved in 
running recently have all had a boolean policy regarding administrative 
privs...

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



--
This message was distributed to subscribers of the selinux mailing 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.