Shared data area

[Daniel J Walsh]

Nicklas Norling wrote:

> Paul Howarth wrote:
>
>> On Wed, 2005-07-20 at 13:34 -0400, Daniel J Walsh wrote:
>>  
>>
>>> Paul Howarth wrote:
>>>
>>>   
>>>
>>>> Daniel J Walsh wrote:
>>>>
>>>>     
>>>>
>>>>> Paul Howarth wrote:
>>>>>
>>>>>       
>>>>>
>>>>>> On Tue, 2005-07-19 at 13:12 +0200, Nicklas Norling wrote:
>>>>>>
>>>>>>
>>>>>>         
>>>>>>
>>>>>>> I would encourage a boolean for shared data location. I think 
>>>>>>> labeling a folder and it's subcontent with a specific label and 
>>>>>>> then have different services be able to use it might be a start. 
>>>>>>> That way I could disallow smb the rights but allow ftpd and 
>>>>>>> httpd (as an example). I think that would be a great improvment 
>>>>>>> from my point of view.
>>>>>>>  
>>>>>>>           
>>>>>>
>>>>>>
>>>>>> I think this is a great idea. I have a file server at home where 
>>>>>> I stick
>>>>>> all the software I've downloaded, some for Linux and some for 
>>>>>> Windows.
>>>>>> The Windows box accesses the area using samba and Linux uses 
>>>>>> httpd as
>>>>>> I've set up a local yum repo for the Linux software. So in 
>>>>>> Niklas' idea
>>>>>> I'd be enabling httpd and smb for this and not ftp.
>>>>>>
>>>>>> This type might be a good one to use for everything under /srv...
>>>>>>
>>>>>> Paul.
>>>>>>
>>>>>>
>>>>>>         
>>>>>
>>>>> Ok.  I am allowing ftpd, samba, apache and/or apache scripts, 
>>>>> rsync to read ftpd_anon_t.
>>>>>
>>>>> So if you want files shared by these services, you can change the 
>>>>> context to ftpd_anon_t.
>>>>>       
>>>>
>>>> Would it not be better to create a new type for a shared data area 
>>>> (e.g. srv_data_t), with booleans allowing read/write access to this 
>>>> data for each daemon, rather than overloading an existing type? 
>>>> After all, some process has to set up this data area, and for some 
>>>> people that will be done using ftp, some sftp, some rsync, some 
>>>> samba etc...
>>>>
>>>>     
>>>
>>> I could do that, but I was already sharing the type between rsync 
>>> and ftp.  Basically I think of this type, as data available on the 
>>> network requiring no authorization to read or for ftpd_anon_rw_t, to 
>>> write.  Creating a bunch of booleans for each daemon that might use 
>>> the type, seems like a complexity for limited additional security.  
>>> If I have a server running apache and ftpd, I can't see what the 
>>> difference if allowing them to read the data via the ftp protocol, 
>>> but not via the http protocol.  But I am willing to be persuaded.
>>>   
>>
>>
>> I'd agree on the read side of the discussion. But if you want to
>> maintain this data area using, say, rsync, then you'd need to use
>> ftpd_anon_rw_t to enable writing in the first place, and that would then
>> open up the area to be written by *all* of the daemons unless there were
>> separate write-enable booleans for each daemon. I can certainly see
>> benefits in doing that.
>>
>> Paul.
>>  
>>
> I suppose one could argue that the daemon in question should be set up 
> correctly. read-only or read-write as appropriate. Selinux should not 
> do the applications job or there would be dual systems to keep in sync 
> when policies changes. But I do see your point. I'm afraid I don't 
> know enough about selinux to comment further. Just wanteded to play 
> the devils advocate for awhile.
> /Nicke
>
Ok, I will add booleans for all "shared" domains to write to ftpd_anon_rw_t

> -- 
> fedora-selinux-list mailing list
> fedora-selinux-list at redhat.com
> http://www.redhat.com/mailman/listinfo/fedora-selinux-list



--