jrey at linux.ibm.com
Thu May 14 00:59:21 AEST 2020
On 5/13/20 12:04 AM, Manojkiran Eda wrote:
> Hi Joseph,
> I may not be accurate here, But from what i have learnt - Yes, this
> can be done using "Type Enforcement feature" in SELinux.
> Type Enforcement essentially allows every file/object/process in
> SELinux enabled system to be stored with a security context label as
> an extended attribute.
> And policies can be framed to allow access between various security
> context labelled objects.
> Any access between security contexts - that does not have an
> associated selinux policy will be denied by default.
> Say for example, in this case :
> > I would like to see SELinux limit who can write to files under the /etc
> > directory. For example, bmcweb implements REST APIs add and modify
> > local users, control pam_tally2 account lockout parameters, etc. More
> > specifically, the phosphor-user-manager daemon modifies files like
> > /etc/shadow and /etc/pam.d/common_auth. Only this application should be
> > able to write to these file. Also, this daemon should not be to allowed
> > to write to any other config files.
> 1. A new security label needs to be defined, say *user_manager_t* for
> *phosphor-user-manager* service and this context can be attached to
> the service through the SELinux tag in the dbus-configuration xml
> file. so that when the user-manager service executes it obtains a
> security context type of *user_manager_t*.
> 2. As far as i know the files in the /*etc* would acquire a security
> context label of *etc_t *by default during the auto relabelling
> process which happens at the first selinux enabled boot of BMC.
> 3. Now we just need to write a selinux policy to allow access between
> *user_manager_t *type with *etc_t* type.
> 4. Any process, example *bmcweb* say has *webserver_t* (does not have
> the security context of *user_manager_t*) would get an access denied
> if it tries to write into the /*etc* files as there is no associated
> 5. We can even assign a security label for each file inside the */etc*
> and write an associated policy for it, so that we can get a granular
> control over who can access which file under */etc*.
Thanks for the details. Yes, using type enforcement sounds right. You
know a lot more about SELinux than I do.
If I understand this correctly, a simpler less-granular design (perhaps
as a proof of concept) that still provides meaningful internal barriers
Define a new label etc_writer_t and attach it only to D-Bus daemons that
need to update config files.
In this way, only those daemons can update confg files, and attackers
coming in through BMCWeb or the host side would not be able to directly
update config files. Doing so may make the attacker's task
significantly more difficult.
> Hope this answers your question.
> ----- Original message -----
> From: Joseph Reynolds <jrey at linux.ibm.com>
> Sent by: "openbmc"
> <openbmc-bounces+manojeda=in.ibm.com at lists.ozlabs.org>
> To: Manojkiran Eda <manojeda at in.ibm.com>,
> openbmc at lists.ozlabs.org, rnouse at google.com
> Cc: ratagupt at linux.vnet.ibm.com
> Subject: [EXTERNAL] Re: SELinux UseCases
> Date: Tue, May 12, 2020 11:48 PM
> On 5/10/20 11:34 PM, Manojkiran Eda wrote:
> > Hi All,
> > This is a just a ping - to generate a discussion on the below
> > mentioned use-cases.
> > Appreciate any inputs/comments.
> Thanks for putting this together.
> I would like to see SELinux limit who can write to files under the
> directory. For example, bmcweb implements REST APIs add and modify
> local users, control pam_tally2 account lockout parameters, etc. More
> specifically, the phosphor-user-manager daemon modifies files like
> /etc/shadow and /etc/pam.d/common_auth. Only this application
> should be
> able to write to these file. Also, this daemon should not be to
> to write to any other config files.
> - Joseph
> > Thanks,
> > Manoj
> > ----- Original message -----
> > From: Manojkiran Eda/India/IBM
> > To: openbmc at lists.ozlabs.org, rnouse at google.com
> > Cc: ratagupt at linux.vnet.ibm.com
> > Subject: SELinux UseCases
> > Date: Thu, Apr 30, 2020 6:50 PM
> > Hi All,
> > (My apologies for the lengthy email.)
> > Below are few use-cases in BMC, which i feel inclusion of
> > would be a value add (there could be may more missing). Please
> > feel free to drop-in your comments/feedback.
More information about the openbmc