support for fireflight reading /proc/NNN/fd and /proc/NNN/exe

support for fireflight reading /proc/NNN/fd and /proc/NNN/exe

[Luke Kenneth Casson Leighton]

hi,

got an interesting issue that i don't quite know how to tackle.

i picked fireflight because it's exactly the sort of thing that i
need to put 
-- 
-- 
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
believing that you have actually started a conversation.
--
<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: support for fireflight reading /proc/NNN/fd and /proc/NNN/exe

[Luke Kenneth Casson Leighton]

hey, what happened?

sorry about that, i must have hit send rather than cancel.

i picked fireflight because it does on-demand popup firewalling,
which i think is great.

the packet(s) is(are) blocked until approved or rejected, and you
can create a rule immediately from them.

also you can firewall _applications_ so only a certain app is allowed
to do "http" etc.


.. the thing is that, obviously, it requires to know the name
of the applications.

so what it does is look in /proc/NNN/exe and /proc/NNN/fds and
looks up the executable...

and thank you to russell for mentioning the can_ps(...) macro which
allows to read /proc.


.. but it also needs to be able to track the files themselves,
getattr, and stuff.

this is what i'm seeing:

	allow fireflier_t ptmx_t:chr_file { getattr };
	allow fireflier_t sound_device_t:chr_file { getattr };
	allow fireflier_t sysadm_ssh_t:tcp_socket { getattr };
	allow fireflier_t sysadm_tty_device_t:chr_file { getattr };
	allow fireflier_t user_devpts_t:chr_file { getattr };
	allow fireflier_t user_home_t:file { getattr };
	allow fireflier_t user_tmp_t:file { getattr };
	allow fireflier_t user_t:fifo_file { getattr };
	allow fireflier_t user_t:tcp_socket { getattr };
	allow fireflier_t user_t:unix_stream_socket { getattr };
	allow fireflier_t xdm_t:fifo_file { getattr };


should i be looking to modify the can_ps macro?

i mean, basically, everything in /proc/NNN/fds, fireflier is
going to try to stat it.

this is can_ps.

	define(`can_ps',`
		allow $1 $2:dir { search getattr read };
		allow $1 $2:{ file lnk_file } { read getattr };
		allow $1 $2:process getattr;
		# We need to suppress this denial because procps tries to access
		# /proc/pid/environ and this now triggers a ptrace check in recent
		# kernels
		# (2.4 and 2.6).  Might want to change procps to not do this, or only if
		# running in a privileged domain.
		dontaudit $1 $2:process ptrace;
	')


should i change this:

	allow $1 $2:{ file lnk_file } { read getattr };

to this:

	allow $1 $2:{ file lnk_file chr_file tcp_socket fifo_file
					unix_stream_socket } { read getattr };


and why, if i have can_ps(fireflier_t, domain), am i still seeing
denied getattr on user_home_t?



.. alternatively, has anyone got any better ideas on how fireflier
should be checking for executable program's names?

l.

p.s. if i _don't_ allow it to look up these program names, i can
expect fireflier to thoroughly lock up the machine as it can't
tell me what to do with a packet, so it gets blocked.

On Mon, Jun 07, 2004 at 08:22:43AM +0000, Luke Kenneth Casson Leighton wrote:
> hi,
> 
> got an interesting issue that i don't quite know how to tackle.
> 
> i picked fireflight because it's exactly the sort of thing that i
> need to put 
> -- 
> -- 
> expecting email to be received and understood is a bit like
> picking up the telephone and immediately dialing without
> checking for a dial-tone; speaking immediately without listening
> for either an answer or ring-tone; hanging up immediately and
> believing that you have actually started a conversation.
> --
> <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.

-- 
-- 
expecting email to be received and understood is a bit like
picking up the telephone and immediately dialing without
checking for a dial-tone; speaking immediately without listening
for either an answer or ring-tone; hanging up immediately and
believing that you have actually started a conversation.
--
<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: support for fireflight reading /proc/NNN/fd and /proc/NNN/exe

[Thomas Bleher]

[-- Attachment #1: Type: text/plain, Size: 2363 bytes --]

* Luke Kenneth Casson Leighton <lkcl@lkcl.net> [2004-06-08 00:50]:
> i picked fireflight because it does on-demand popup firewalling,
> which i think is great.
<snip>
> so what it does is look in /proc/NNN/exe and /proc/NNN/fds and
> looks up the executable...
<snip> 
> .. but it also needs to be able to track the files themselves,
> getattr, and stuff.
> 
> this is what i'm seeing:
> 
> 	allow fireflier_t ptmx_t:chr_file { getattr };
> 	allow fireflier_t sound_device_t:chr_file { getattr };
> 	allow fireflier_t sysadm_ssh_t:tcp_socket { getattr };
> 	allow fireflier_t sysadm_tty_device_t:chr_file { getattr };
> 	allow fireflier_t user_devpts_t:chr_file { getattr };
> 	allow fireflier_t user_home_t:file { getattr };
> 	allow fireflier_t user_tmp_t:file { getattr };
> 	allow fireflier_t user_t:fifo_file { getattr };
> 	allow fireflier_t user_t:tcp_socket { getattr };
> 	allow fireflier_t user_t:unix_stream_socket { getattr };
> 	allow fireflier_t xdm_t:fifo_file { getattr };
> 
> 
> should i be looking to modify the can_ps macro?

Not the macro directly, otherwise all domains which use can_ps() will be
affected. If you really need that much access, you should probably add a
rule like
        allow fireflier_t file_type:file_class_set getattr;
        allow fireflier_t domain:{ socket_class_set fifo_file } getattr;
But this seems just too broad (see below).

> i mean, basically, everything in /proc/NNN/fds, fireflier is
> going to try to stat it.
> 
<snip>

> and why, if i have can_ps(fireflier_t, domain), am i still seeing
> denied getattr on user_home_t?

user_home_t doesn't have the "domain"-attribute.

> .. alternatively, has anyone got any better ideas on how fireflier
> should be checking for executable program's names?

How about /proc/<pid>/exe ?
 
> p.s. if i _don't_ allow it to look up these program names, i can
> expect fireflier to thoroughly lock up the machine as it can't
> tell me what to do with a packet, so it gets blocked.

I still don't get why it needs to look at all fds and stat all the
files. Could you tell us why it needs to stat all open filehandles to
find the program name?

A little bit confused,
Thomas

-- 
http://www.cip.ifi.lmu.de/~bleher/selinux/ - my SELinux pages
GPG-Fingerprint: BC4F BB16 30D6 F253 E3EA  D09E C562 2BAE B2F4 ABE7

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: support for fireflight reading /proc/NNN/fd and /proc/NNN/exe

[Luke Kenneth Casson Leighton]

On Tue, Jun 08, 2004 at 01:21:59AM +0200, Thomas Bleher wrote:

> * Luke Kenneth Casson Leighton <lkcl@lkcl.net> [2004-06-08 00:50]:
> > i picked fireflight because it does on-demand popup firewalling,
> > which i think is great.
> <snip>
> > so what it does is look in /proc/NNN/exe and /proc/NNN/fds and
> > looks up the executable...
> <snip> 
> > .. but it also needs to be able to track the files themselves,
> > getattr, and stuff.
> > 
> > this is what i'm seeing:
> > 
> > 	allow fireflier_t ptmx_t:chr_file { getattr };
> > 	allow fireflier_t sound_device_t:chr_file { getattr };
> > 	allow fireflier_t sysadm_ssh_t:tcp_socket { getattr };
> > 	allow fireflier_t sysadm_tty_device_t:chr_file { getattr };
> > 	allow fireflier_t user_devpts_t:chr_file { getattr };
> > 	allow fireflier_t user_home_t:file { getattr };
> > 	allow fireflier_t user_tmp_t:file { getattr };
> > 	allow fireflier_t user_t:fifo_file { getattr };
> > 	allow fireflier_t user_t:tcp_socket { getattr };
> > 	allow fireflier_t user_t:unix_stream_socket { getattr };
> > 	allow fireflier_t xdm_t:fifo_file { getattr };
> > 
> > 
> > should i be looking to modify the can_ps macro?
> 
> Not the macro directly, otherwise all domains which use can_ps() will be
> affected. If you really need that much access, you should probably add a
> rule like
>         allow fireflier_t file_type:file_class_set getattr;
>         allow fireflier_t domain:{ socket_class_set fifo_file } getattr;
> But this seems just too broad (see below).
> 
> > i mean, basically, everything in /proc/NNN/fds, fireflier is
> > going to try to stat it.
> > 
> <snip>
> 
> > and why, if i have can_ps(fireflier_t, domain), am i still seeing
> > denied getattr on user_home_t?
> 
> user_home_t doesn't have the "domain"-attribute.
> 
> > .. alternatively, has anyone got any better ideas on how fireflier
> > should be checking for executable program's names?
> 
> How about /proc/<pid>/exe ?
>
 yes, it does that, _and_ parses /proc/<pid>/fds/* as well.

> > p.s. if i _don't_ allow it to look up these program names, i can
> > expect fireflier to thoroughly lock up the machine as it can't
> > tell me what to do with a packet, so it gets blocked.
> 
> I still don't get why it needs to look at all fds and stat all the
> files. Could you tell us why it needs to stat all open filehandles to
> find the program name?
 
 .... mmmm.... fireflier-1.14/server/ports.cpp:

	// search for the pid using localport/localip pair
	// calling the other functions. This could be used from another program
	// too.
	// mode = PROT_TCP ---> tcp port
	// mode = PROT_UDP ---> udp port
	int get_pid(int mode, int local_ip, int local_port)
	{
		int inode=-1;

and later:

	// search for the program using this localport/localip.
	// first look into cache
	// search the pid
	// if found look onto /proc/PID/exe
	// put into cache
	// mode = PROT_TCP  ----> tcp
	// mode = PROT_UDP  ----> udp
	char *get_program_name(int mode, int local_ip, int local_port)
	{

wow, cool -  useful comments.


so, the program does this:

* scans /proc/net/tcp and /proc/net/udp looking for a match on
  local_port and ip, and returns the inode doing that.

* scans ALL of /proc/<pid>/fds/* doing a stat() on every single one
  to look up the inode.

* once found, looks up /proc/<matchingpid>/exe

voila.

now, i notice that names of /proc/<pid>/fds/N when it's a socket,
the name is socket:something.

1) can that convention be followed / respected?  i.e. if
(strncmp("socket:", fdname) == 0) proceed otherwise skip?

2) is there a better way?

i mean, how does lsof do this? [download]  ah... lsof is thoroughly
archaic, short-named variables and completely incomprehensible and
untrackeable code: stuff _that_.

martin if you decide to investigate lsof, good luck :)

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: support for fireflight reading /proc/NNN/fd and /proc/NNN/exe

[Stephen Smalley]

On Mon, 2004-06-07 at 19:21, Thomas Bleher wrote:
> Not the macro directly, otherwise all domains which use can_ps() will be
> affected. If you really need that much access, you should probably add a
> rule like
>         allow fireflier_t file_type:file_class_set getattr;
>         allow fireflier_t domain:{ socket_class_set fifo_file } getattr;
> But this seems just too broad (see below).

Definitely too broad.  Use dontaudit rules to suppress the audit
messages, and only allow it what it truly needs to function.

-- 
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: support for fireflight reading /proc/NNN/fd and /proc/NNN/exe

[Luke Kenneth Casson Leighton]

On Tue, Jun 08, 2004 at 01:11:10PM -0400, Stephen Smalley wrote:
> On Mon, 2004-06-07 at 19:21, Thomas Bleher wrote:
> > Not the macro directly, otherwise all domains which use can_ps() will be
> > affected. If you really need that much access, you should probably add a
> > rule like
> >         allow fireflier_t file_type:file_class_set getattr;
> >         allow fireflier_t domain:{ socket_class_set fifo_file } getattr;
> > But this seems just too broad (see below).
> 
> Definitely too broad.  Use dontaudit rules to suppress the audit
> messages, and only allow it what it truly needs to function.
 
 i've spoken to martin and he accepted a patch on fireflight
 to restrict the stat operations to only those files where
 the symlink name begins with "socket:".

 if anyone with severe linux kernel knowledge (and isn't afraid
 to admit it) can forsee any problems with that approach, please do
 say so!

 martin says the code to do the /proc/<pid>/ walking he
 cut/paste from netstat so gawd only knows what horrors netstat
 gets up to.

 lsof i'd kinda expect to be better behaved and to know a few
 more kernel /proc tricks but for the life of me i can't work
 it out.  i seriously can't be bothered, the code is monster
 spaghetti and looks totally unmaintainable.

 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.