From: dominick.grift@gmail.com (Dominick Grift)
Date: Mon, 06 Aug 2012 17:30:46 +0200
Subject: [refpolicy] [PATCH v2]: mcelog module initial rewrite
In-Reply-To: <201208061519.q76FJcDp011962@vivaldi31.register.it>
References: <201208061519.q76FJcDp011962@vivaldi31.register.it>
Message-ID: <1344267046.29329.57.camel@d30.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Mon, 2012-08-06 at 17:19 +0200, Guido Trentalancia wrote:
> If we keep bin_t, then we need to use corecmd_exec_bin() or whatever that is called, which means it can execute any script and in particular any binary.
> 
> So, the good reason is restricting the type of files that mcelog can execute. In my opinion policy should always been designed that way, when the application needs to execute internal (or user-defined) scripts or binaries (as opposed to system-wide executables in /bin, /sbin, /usr/bin or /usr/sbin).
> 
> Unless you give me a good reason, I won't change that.

The only good reason i can come up with right now is that if you change
this the maintainer might not accept the patch.

> Ok. I will create a third version (v3) with further changes as necessary.

This interface is not needed at all.

> >
> >Not needed.
> 
> You suggested (initial review):
> 
> allow mcelog_t self:unix_stream_socket create_socket_perms;
> 
> I have just turned that into an interface...
> 
> So, I don't get the point now.

You should not create an interface for that. Just add it to the
mcelog.te file (but use create_stream_socket_perms instead, my mistake)

> I think it gets audited as denied otherwise (possibly the client mode). If time allows, I'll double-check.

If you add: allow mcelog_t self:unix_stream_socket
create_stream_socket_perms; to mcelog.te this will be allowed i think

> In client-mode it needs to connect to the socket.
> 
> Has the feature been removed in subsequent versions ? I can't find it anymore on kernel.org...

That's not my point. This is already allowed.

mcelog_t already has full access to mcelog_var_run_t sockets and if you
add allow mcelog_t self:unix_stream_socket create_stream_socket_perms;
to mcelog.te then mcelog_t will also be allowed to connect via unix
stream socket.

> Otherwise, if they are labelled differently for increased security as explained above, it should need both corecmd_executable_file() and can_exec() on the private executable type.

There is not much increased security in my view.

> >
> 
> To be honest I would rather prefer not using bin_t. Perhaps, it needs to be able to transition from the private exec type ?

Assumption is bad. Until proven otherwise bin_t seems fine.

> 
> As far as I know other modules are using interfaces internally. I will double-check and if neccessary remove them.

some modules are using local templates, i guess this is a exception to
the rule. Calling internal interfaces should not be done.

> term_use_all_ttys() is needed for interactive use. Do you know anything more restrictive than that ?

I would need to see the avc denial to make a judgement