banning copying of binaries (e.g. mozilla etc).

banning copying of binaries (e.g. mozilla etc).

[Luke Kenneth Casson Leighton]

okay, got a weird issue where i am curious as to whether selinux could
help.

imagine that ipt_owner has been successfully hacked up (hacked as in
the literal and true meaning of the word not the one the press associate
with it) to support program names (or as a last resort inodes) as part
of the checking / filtering rules.

i.e. like fireflier's rather buggy userspace support for allowing
e.g. mozilla to do port 80 and port 445 but NOT any other program,
only done properly and in the kernel.

now imagine that someone bypasses these rules by simply copying the
binary.

in this way, they would be able to at the very least bypass "DENY"
rules.

my question is, therefore, is there an easy way to ban users from
copying binaries, whilst still allowing users to run them?

l.

-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: banning copying of binaries (e.g. mozilla etc).

[Joshua Brindle]

Luke Kenneth Casson Leighton wrote:

>okay, got a weird issue where i am curious as to whether selinux could
>help.
>
>imagine that ipt_owner has been successfully hacked up (hacked as in
>the literal and true meaning of the word not the one the press associate
>with it) to support program names (or as a last resort inodes) as part
>of the checking / filtering rules.
>
>i.e. like fireflier's rather buggy userspace support for allowing
>e.g. mozilla to do port 80 and port 445 but NOT any other program,
>only done properly and in the kernel.
>
>now imagine that someone bypasses these rules by simply copying the
>binary.
>
>in this way, they would be able to at the very least bypass "DENY"
>rules.
>
>my question is, therefore, is there an easy way to ban users from
>copying binaries, whilst still allowing users to run them?
>
>l.
>
>  
>
I'm not sure what you are talking about here, there is no such thing as 
a "deny" rule in selinux, everything is denied by default.
What you want to do is simply restrict the user domains from doing the 
things you don't want, and giving only, say, mozilla the access it 
needs. That way if they do copy the binary to their home it'll be 
staff_home_t and can 1) either be denied execute by staff_t or 2) be 
allowed to execute_no_trans so that anything it does is contrained by 
the users domain restrictions. Futher, you can give user domains access 
to execute binaries without reading them, this should work fine but that 
is an incomplete solution. The bottom line is you can not easily keep 
users from getting binaries onto the system, all you can do is prevent 
them from executing them or only let them execute them in their 
restricted domains.

Joshua Brindle

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: banning copying of binaries (e.g. mozilla etc).

[Luke Kenneth Casson Leighton]

On Mon, Aug 30, 2004 at 07:33:12PM -0400, Joshua Brindle wrote:
> Luke Kenneth Casson Leighton wrote:
> 
> >okay, got a weird issue where i am curious as to whether selinux could
> >help.
> >
> >imagine that ipt_owner has been successfully hacked up (hacked as in
> >the literal and true meaning of the word not the one the press associate
> >with it) to support program names (or as a last resort inodes) as part
> >of the checking / filtering rules.
> >
> >i.e. like fireflier's rather buggy userspace support for allowing
> >e.g. mozilla to do port 80 and port 445 but NOT any other program,
> >only done properly and in the kernel.
> >
> >now imagine that someone bypasses these rules by simply copying the
> >binary.
> >
> >in this way, they would be able to at the very least bypass "DENY"
> >rules.
> >
> >my question is, therefore, is there an easy way to ban users from
> >copying binaries, whilst still allowing users to run them?
> >
> >l.
> >
> > 
> >
> I'm not sure what you are talking about here, there is no such thing as 
> a "deny" rule in selinux, everything is denied by default.

 yes - and somewhere, there's a "allow read bin_t" rule which i
 naively thought it would be possible to remove in order to achieve
 the desired effect...

> What you want to do is simply restrict the user domains from doing the 
> things you don't want, and giving only, say, mozilla the access it 
> needs. That way if they do copy the binary to their home it'll be 
> staff_home_t and can 1) either be denied execute by staff_t or 2) be 
> allowed to execute_no_trans so that anything it does is contrained by 
> the users domain restrictions. Futher, you can give user domains access 
> to execute binaries without reading them, this should work fine but that 
> is an incomplete solution. The bottom line is you can not easily keep 
> users from getting binaries onto the system, all you can do is prevent 
> them from executing them or only let them execute them in their 
> restricted domains.

 ... but if i understand correctly, it would be better to look for
 where user_t is granted execute_no_trans (in the big user macros)
 to user_u:object_r:user_t (well it's going to be allow $1_t) and
 remove that?

 l.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: banning copying of binaries (e.g. mozilla etc).

[Stephen Smalley]

On Mon, 2004-08-30 at 18:23, Luke Kenneth Casson Leighton wrote:
> okay, got a weird issue where i am curious as to whether selinux could
> help.
> 
> imagine that ipt_owner has been successfully hacked up (hacked as in
> the literal and true meaning of the word not the one the press associate
> with it) to support program names (or as a last resort inodes) as part
> of the checking / filtering rules.
>
> i.e. like fireflier's rather buggy userspace support for allowing
> e.g. mozilla to do port 80 and port 445 but NOT any other program,
> only done properly and in the kernel.

SELinux already allows you to control port binding and socket IPC based
on the domain, which can encode information about the program as well as
the caller.  Why do you need additional state and mechanism?

> now imagine that someone bypasses these rules by simply copying the
> binary.
> 
> in this way, they would be able to at the very least bypass "DENY"
> rules.

You mean "deny program FOO the ability to do X"?  That seems pointless;
you want to define the set of approved programs, not the set of denied
programs, as people can alway construct new programs outside of any
blacklist.

> my question is, therefore, is there an easy way to ban users from
> copying binaries, whilst still allowing users to run them?

The policy can certainly prohibit a given domain from executing anything
it can create/write.  But I still don't see what you are trying to
achieve.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: banning copying of binaries (e.g. mozilla etc).

[Luke Kenneth Casson Leighton]

On Tue, Aug 31, 2004 at 07:29:48AM -0400, Stephen Smalley wrote:
> On Mon, 2004-08-30 at 18:23, Luke Kenneth Casson Leighton wrote:
> > okay, got a weird issue where i am curious as to whether selinux could
> > help.
> > 
> > imagine that ipt_owner has been successfully hacked up (hacked as in
> > the literal and true meaning of the word not the one the press associate
> > with it) to support program names (or as a last resort inodes) as part
> > of the checking / filtering rules.
> >
> > i.e. like fireflier's rather buggy userspace support for allowing
> > e.g. mozilla to do port 80 and port 445 but NOT any other program,
> > only done properly and in the kernel.
> 
> SELinux already allows you to control port binding and socket IPC based
> on the domain, which can encode information about the program as well as
> the caller.  Why do you need additional state and mechanism?
 
 ... so it acts a bit like a firewall in this respect?

 and, can the _user_ decide to add rules such as mozilla can access
 port 8080?

 [assuming that i want to _allow_ users to be able to do that of course]

> > now imagine that someone bypasses these rules by simply copying the
> > binary.
> > 
> > in this way, they would be able to at the very least bypass "DENY"
> > rules.
> 
> You mean "deny program FOO the ability to do X"?  

 DENY as in iptables "DENY" rule.

 the parallels / lessons to be learned between writing selinux policy
 and writing iptables firewall rules are very clear.

 as steven tweedie said in the tutorials (written by russ et al) the
 strict policy you start off with "deny all" and you do "allow" you
 NEVER do "deny one" in strict policy.

 whereas with the "targetted" policy it's the other way round.

 so, likewise, it is necessary to have a strict firewall policy
 where DENY ALL is the default, and "allow one" is added and you
 NEVER do "deny one".

 therefore, that someone raised on the LKML "be careful about adding
 DENY rules" is a bit of a moot point.



> That seems pointless;
> you want to define the set of approved programs, not the set of denied
> programs, as people can alway construct new programs outside of any
> blacklist.
> 
> > my question is, therefore, is there an easy way to ban users from
> > copying binaries, whilst still allowing users to run them?
> 
> The policy can certainly prohibit a given domain from executing anything
> it can create/write.  But I still don't see what you are trying to
> achieve.

 under the circumstances under which someone fails to abide by the good
 practice of not adding a DENY firewall rule in a "strict" iptables
 policy [i.e. the default is DENY ALL at the bottom of the iptables
 chain] then:

 i would like to provide a mechanism whereby any binary that has an
 associated DENY-firewall rule with it, that someone cannot simply
 copy that binary to a different name, run _that_ binary and thereby
 bypass the DENY-firewall rule [associated with the original binary].


 .... in fact.... come to think of it.... isn't there a lesson to be
 learned here with the targetted policy?

 if the rules are by default "allow all" and "deny individual", then
 surely by copying a binary and running it, it's possible to bypass
 the "deny individual" rules???

 tell me that's not so...


-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: banning copying of binaries (e.g. mozilla etc).

[Stephen Smalley]

On Tue, 2004-08-31 at 08:25, Luke Kenneth Casson Leighton wrote:
>  ... so it acts a bit like a firewall in this respect?

Yes, but on the basis of process domains.  Not intended to replace a
traditional firewall, but to allow control of data flow among domains
via socket IPC.  To completely support this, one needs labeled
networking, but the existing mechanism lets you at least control locally
based on process domain, port type, netif type, and node type.

>  and, can the _user_ decide to add rules such as mozilla can access
>  port 8080?

This can be checked on the client side, as the client OS can perform a
check based on the sending process domain and the destination port
type.  In order to do it on the server side as well, we would need
labeled networking to convey the sending process domain to the server
OS.  The policy administrator can define such rules.  For user-definable
rules, you would need a policy daemon that allows users to apply
specific well-defined changes to the policy without completely changing
it.

>  whereas with the "targetted" policy it's the other way round.

That's not really accurate.  The targeted policy still has to define
everything that is allowed.  It is true that in the targeted policy,
most processes are placed into an unconfined_t domain that is allowed to
do anything by the policy, and only a specific set of processes are
placed into separate domains that are limited.

>  i would like to provide a mechanism whereby any binary that has an
>  associated DENY-firewall rule with it, that someone cannot simply
>  copy that binary to a different name, run _that_ binary and thereby
>  bypass the DENY-firewall rule [associated with the original binary].

As I said, you can prevent a domain from executing anything it can
create/write, and this is good practice for daemons, but difficult to
impose on users.  Simply preventing copying is pointless.

>  .... in fact.... come to think of it.... isn't there a lesson to be
>  learned here with the targetted policy?
> 
>  if the rules are by default "allow all" and "deny individual", then
>  surely by copying a binary and running it, it's possible to bypass
>  the "deny individual" rules???
> 
>  tell me that's not so...

That isn't the way targeted policy works.  It still has to specify
everything allowed; it just allows more.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: banning copying of binaries (e.g. mozilla etc).

[Luke Kenneth Casson Leighton]

On Tue, Aug 31, 2004 at 08:34:54AM -0400, Stephen Smalley wrote:
> On Tue, 2004-08-31 at 08:25, Luke Kenneth Casson Leighton wrote:
> >  ... so it acts a bit like a firewall in this respect?
> 
> Yes, but on the basis of process domains.  Not intended to replace a
> traditional firewall, but to allow control of data flow among domains
> via socket IPC.  To completely support this, one needs labeled
> networking, but the existing mechanism lets you at least control locally
> based on process domain, port type, netif type, and node type.
 
 ... so port type equates to port number.

> >  and, can the _user_ decide to add rules such as mozilla can access
> >  port 8080?
> 
> This can be checked on the client side, as the client OS can perform a
> check based on the sending process domain and the destination port
> type.  In order to do it on the server side as well, we would need
> labeled networking to convey the sending process domain to the server
> OS.  The policy administrator can define such rules.  For user-definable
> rules, you would need a policy daemon that allows users to apply
> specific well-defined changes to the policy without completely changing
> it.
> 
> >  whereas with the "targetted" policy it's the other way round.
> 
> That's not really accurate.  

 ah - an oversimplified tutorial to make it easy to understand.

> >  i would like to provide a mechanism whereby any binary that has an
> >  associated DENY-firewall rule with it, that someone cannot simply
> >  copy that binary to a different name, run _that_ binary and thereby
> >  bypass the DENY-firewall rule [associated with the original binary].
> 
> As I said, you can prevent a domain from executing anything it can
> create/write, and this is good practice for daemons, but difficult to
> impose on users.  Simply preventing copying is pointless.
 
 ... but it would be easy to, say, deny users the ability to execute
 user_u:object_r:user_t binaries, or default_t binaries etc. yes?


> >  if the rules are by default "allow all" and "deny individual", then
> >  surely by copying a binary and running it, it's possible to bypass
> >  the "deny individual" rules???
> > 
> >  tell me that's not so...
> 
> That isn't the way targeted policy works.  It still has to specify
> everything allowed; it just allows more.
 
  *whew*.

-- 
--
Truth, honesty and respect are rare commodities that all spring from
the same well: Love.  If you love yourself and everyone and everything
around you, funnily and coincidentally enough, life gets a lot better.
--
<a href="http://lkcl.net">      lkcl.net      </a> <br />
<a href="mailto:lkcl@lkcl.net"> lkcl@lkcl.net </a> <br />


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: banning copying of binaries (e.g. mozilla etc).

[Stephen Smalley]

On Tue, 2004-08-31 at 09:27, Luke Kenneth Casson Leighton wrote:
>  ... so port type equates to port number.

The net_contexts configuration maps port numbers to port types, so you
can group them into equivalence classes.  Note that there has been a
recent change to checkpolicy (in the sourceforge CVS tree) in this area
to preserve the specified ordering for matching so that you can have
overlapping port ranges, and a general entry for ports 1-1023 has been
added to net_contexts to map them all to reserved_port_t if not
otherwise specified.

>  ... but it would be easy to, say, deny users the ability to execute
>  user_u:object_r:user_t binaries, or default_t binaries etc. yes?

user_home_t?  Yes.  If you look at macros/base_user_macros.te, you'll
see the specific can_exec() rules that allow the user domains to execute
files in their home directories and their own temporary files in the
current policy.  You would want to go through and remove all such rules
for any type that the user can create/write.  apol is your friend for
such analysis, as it can quickly find all cases including those covered
by rules that use type attributes.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: banning copying of binaries (e.g. mozilla etc).

[Joshua Brindle]

Stephen Smalley wrote:

> On Tue, 2004-08-31 at 09:27, Luke Kenneth Casson Leighton wrote:
> 
>> ... so port type equates to port number.
> 
> 
> The net_contexts configuration maps port numbers to port types, so you
> can group them into equivalence classes.  Note that there has been a
> recent change to checkpolicy (in the sourceforge CVS tree) in this area
> to preserve the specified ordering for matching so that you can have
> overlapping port ranges, and a general entry for ports 1-1023 has been
> added to net_contexts to map them all to reserved_port_t if not
> otherwise specified.
> 
> 
>> ... but it would be easy to, say, deny users the ability to execute
>> user_u:object_r:user_t binaries, or default_t binaries etc. yes?
> 
> 
> user_home_t?  Yes.  If you look at macros/base_user_macros.te, you'll
> see the specific can_exec() rules that allow the user domains to execute
> files in their home directories and their own temporary files in the
> current policy.  You would want to go through and remove all such rules
> for any type that the user can create/write.  apol is your friend for
> such analysis, as it can quickly find all cases including those covered
> by rules that use type attributes.
> 
It's worth noting that this will not stop execution of said binaries 
entirely. One only needs to know enough to use /lib/ld.so to run any 
dynamically linked binary which he doesn't have execute access on. 
Unfortunatly disabling user domains access to ld.so would make him 
unable to run any dynamically linked apps whatsoever, sounds like we 
need a userland enforcer in glibc ;)

Joshua Brindle

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: banning copying of binaries (e.g. mozilla etc).

[Stephen Smalley]

On Tue, 2004-08-31 at 12:25, Joshua Brindle wrote:
> It's worth noting that this will not stop execution of said binaries 
> entirely. One only needs to know enough to use /lib/ld.so to run any 
> dynamically linked binary which he doesn't have execute access on. 
> Unfortunatly disabling user domains access to ld.so would make him 
> unable to run any dynamically linked apps whatsoever, sounds like we 
> need a userland enforcer in glibc ;)

Running it via ld.so should still trigger SELinux permission checks for
read and execute (upon the mmap) and possibly other checks induced by
earlier operations by ld.so (e.g. stat'ing the file will require
getattr), so this only has an affect on the execute_no_trans check.

With regard to the latter point, the kernel doesn't check
execute_no_trans to the interpreter when handling an execve itself, so
you can remove execute_no_trans permission to ld.so from a domain to
prevent direct execution while still allowing the kernel to invoke it on
behalf of the process upon an execve.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: banning copying of binaries (e.g. mozilla etc).

[Joshua Brindle]

Stephen Smalley wrote:

> On Tue, 2004-08-31 at 12:25, Joshua Brindle wrote:
> 
>>It's worth noting that this will not stop execution of said binaries 
>>entirely. One only needs to know enough to use /lib/ld.so to run any 
>>dynamically linked binary which he doesn't have execute access on. 
>>Unfortunatly disabling user domains access to ld.so would make him 
>>unable to run any dynamically linked apps whatsoever, sounds like we 
>>need a userland enforcer in glibc ;)
> 
> 
> Running it via ld.so should still trigger SELinux permission checks for
> read and execute (upon the mmap) and possibly other checks induced by
> earlier operations by ld.so (e.g. stat'ing the file will require
> getattr), so this only has an affect on the execute_no_trans check.
> 
> With regard to the latter point, the kernel doesn't check
> execute_no_trans to the interpreter when handling an execve itself, so
> you can remove execute_no_trans permission to ld.so from a domain to
> prevent direct execution while still allowing the kernel to invoke it on
> behalf of the process upon an execve.
> 

Ah, my mistake. Out of curiousity why does the ld_so_t have execute 
permission in the uses_shlib macro if the kernel is executing it? Does 
the kernel still check for execute permission for the current domain 
before it executes ld.so?

Joshua Brindle

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: banning copying of binaries (e.g. mozilla etc).

[Stephen Smalley]

On Tue, 2004-08-31 at 13:00, Joshua Brindle wrote:
> Ah, my mistake. Out of curiousity why does the ld_so_t have execute 
> permission in the uses_shlib macro if the kernel is executing it? Does 
> the kernel still check for execute permission for the current domain 
> before it executes ld.so?

The kernel calls open_exec() on the interpreter, which calls
permission() with MAY_EXEC, so SELinux ends up performing a parallel
execute check.  But we don't perform another execute_no_trans check. 
One could likely even remove execute_no_trans to ld.so from can_exec_any
and only break a few domains such as prelink.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.