web-controlled system

[Daniel J Walsh]

Florin Andrei wrote:

>On Fri, 2005-06-03 at 17:46 +1000, Russell Coker wrote:
>  
>
>>On Friday 03 June 2005 17:27, Florin Andrei <florin at andrei.myip.org> wrote:
>>    
>>
>>>On Fri, 2005-06-03 at 16:29 +1000, Russell Coker wrote:
>>>      
>>>
>>>>Probably the easiest solution will be to have Apache or the CGI-BIN
>>>>script in question running unconfined.
>>>>        
>>>>
>>>True, but I'd like to avoid that.
>>>      
>>>
>>If Apache can change system configuration files and restart daemons then 
>>what's the point of trying to restrict it?  Using Apache to configure the 
>>system to boot without SE Linux enabled should be easy enough.
>>    
>>
>
>It's not supposed to change everything. The system will be a "black box"
>to the users who have access to it solely through the Web interface, but
>that interface is not all-powerful. Some daemons can be tweaked, some
>system parameters can be changed, but the interface will not and should
>not have discretionary powers.
>
>I'd like to retain some of the protection offered by SELinux.
>
>  
>
>>The problem you face is how to change the labels on some file so that 
>>Apache can write to them but not grant Apache write to too many things.  If 
>>your requirement is "control everything over the web" then this may not be a 
>>solvable problem.
>>    
>>
>
>Ok, I see. My mistake - the interface doesn't control everything.
>
>I'm thinking about this: how about I leave the policy alone, create a
>small daemon (in Perl, whatever) that's listening on a Unix socket, then
>the Web interface is just passing the commands to the daemon.
>The daemon compares them to a list of "known good commands", maybe makes
>some other verifications, then goes ahead and executes the commands.
>This way I retain the original tight policy, plus I get a supplemental
>level of intelligence in validating what gets sent to the system via the
>interface.
>
>I dunno, this might be a method that would be interesting for more
>people using selinux that want to keep selinux but still be able to have
>a deeper control over the system.
>
>  
>
>>>I'd imagine that by exercising the daemon in all ways possible, and
>>>keeping an eye on syslog at the same time, I should be able to figure
>>>out what needs to be permitted in the policy, right?
>>>      
>>>
>>Correct.
>>    
>>
>
><sigh> I wish there was a concrete example somewhere on how to do that.
>It's not like SELinux doesn't have any docs at all but... So many things
>to do, so little time...
>
>  
>
You can begin defining the policy via

apache_domain.

After installing selinux-policy-targeted-sources
I would start out by creating a te file.

cd /etc/selinux/targetd/src/policy
echo apache_domain(mycgi) >> domains/program/mycgi.te
echo "/var/www/cgi-bin/mycgi -- 
system_u:object_r:httpd_mycgi_script_exec_t" > 
file_contexts/program/mycgi.te
make load
restorecon /var/www/cgi-bin/mycgi
setenforce 0

Start using the mycgi script file.  Gather the avc messages and start 
using audit2allow to generate rules for the script.
Lather; Rinse; Repeat.

Dan


--