Hi Dominick et ALL,
Hope you're well.
I have a question around service confinement when on a system the users are not being confined - Let's take the example of httpd. So, the httpd service is confined as default within RHEL.
However, on a system given that user confinement is not being implemented, from an SELinux perspective, what extra measures can be taken? Or will system service confinement suffice?
More generally, what is the consensus around confining services without concurrently confining users?
Thanks.
Best Regards,
Walid Fakim
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20161017/d9588afe/attachment.html
On 10/17/16 17:29, Fakim, Walid via refpolicy wrote:
> I have a question around service confinement when on a system the users
> are not being confined ? Let?s take the example of httpd. So, the httpd
> service is confined as default within RHEL.
>
> However, on a system given that user confinement is not being
> implemented, from an SELinux perspective, what extra measures can be
> taken? Or will system service confinement suffice?
>
> More generally, what is the consensus around confining services without
> concurrently confining users?
It depends on what your goals are. Distributions typically don't too
much confinement on users because average users aren't expecting their
users to be confined more than the regular Linux DAC. Targeting
services allows most people to keep SELinux enforcing and gain some
security benefits.
If you leave your users unconfined, then you're saying that you
completely trust your users (from the SELinux perspective) and only want
to rely on Linux DAC protections. The problem with this amount of trust
is that many users run web browsers or other network clients that may
not be so trustworthy, which is why web browsers typically have some
confinement and also why tools like sandbox exist.
--
Chris PeBenito
On 10/17/2016 11:29 PM, Fakim, Walid via refpolicy wrote:
> Hi Dominick et ALL,
>
> Hope you're well.
>
> I have a question around service confinement when on a system the users are not being confined - Let's take the example of httpd. So, the httpd service is confined as default within RHEL.
>
> However, on a system given that user confinement is not being implemented, from an SELinux perspective, what extra measures can be taken? Or will system service confinement suffice?
>
> More generally, what is the consensus around confining services without concurrently confining users?
>
> Thanks.
>
> Best Regards,
>
> Walid Fakim
>
>
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
This is a nice blog for some context:
http://blog.ometer.com/2016/05/04/professional-corner-cutting/
Now that you have read the above, consider the following: SELinux is a
tool in the security toolbox of a security specialist
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20161018/6e08183c/attachment.bin
On Monday, 17 October 2016 9:05:25 PM AEDT Chris PeBenito via refpolicy wrote:
> If you leave your users unconfined, then you're saying that you
> completely trust your users (from the SELinux perspective) and only want
> to rely on Linux DAC protections. The problem with this amount of trust
> is that many users run web browsers or other network clients that may
> not be so trustworthy, which is why web browsers typically have some
> confinement and also why tools like sandbox exist.
The problem we have is that in typical usage of a desktop computing
environment a web browser reads and writes so many files that most sysadmins
won't accept a policy that restricts the browser from accessing most files in
the user's home directory. When a web browser can write to ~/.bashrc and
similar files there are no meaningful restrictions on what it can do to the
user's session.
It would be good if tools like sandbox were used more.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/
Thanks both. Makes sense.
Thanks.
Best Regards,
Walid Fakim
-----Original Message-----
From: Russell Coker [mailto:russell at coker.com.au]
Sent: 19 October 2016 06:41
To: refpolicy at oss.tresys.com; Chris PeBenito
Cc: Fakim, Walid
Subject: Re: [refpolicy] Confining services without confining users
On Monday, 17 October 2016 9:05:25 PM AEDT Chris PeBenito via refpolicy wrote:
> If you leave your users unconfined, then you're saying that you
> completely trust your users (from the SELinux perspective) and only
> want to rely on Linux DAC protections. The problem with this amount
> of trust is that many users run web browsers or other network clients
> that may not be so trustworthy, which is why web browsers typically
> have some confinement and also why tools like sandbox exist.
The problem we have is that in typical usage of a desktop computing environment a web browser reads and writes so many files that most sysadmins won't accept a policy that restricts the browser from accessing most files in the user's home directory. When a web browser can write to ~/.bashrc and similar files there are no meaningful restrictions on what it can do to the user's session.
It would be good if tools like sandbox were used more.
--
My Main Blog http://etbe.coker.com.au/
My Documents Blog http://doc.coker.com.au/