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(a)redhat.com
http://www.redhat.com/mailman/listinfo/fedora-selinux-list
--