use of ps in ipsec shutdown

use of ps in ipsec shutdown

[Paul Krumviede]

i've been experimenting with the freeswan-1.91 ipsec implementation
in some of the more recent selinux releases, including the latest 2.4.14
one, and, after making some changes to the supplied ipsec policy,
have come across something i don't yet know how to handle.

i noticed that the supplied policy left some processes in the
initrc_t domain, such as _plutorun and _plutoload. i also noticed
that the ipsec startup script invokes logger, and that whack,
running in the initrc_t domain, was being denied permission
to connect to the socket set up by pluto. so i labeled the
/usr/local/sbin/ipsec script, whack, _plutoload, _plutoread
and whack as ipsec_exec_t types, and allowed ipsec_t
to execute shells, bin_t and sbin_t things (the latter in part
because the default label of things in /usr/local/lib/ipsec
is sbin_t). this seems to have fixed all the things decribed
above (although i'm open to suggestions as to alternative
approaches).

i also noticed that _startklips wanted (limited) access
to /proc/sys/net/ipsec/icmp, so i gave some sysctl
access.

i later noticed a number of avc denials at shutdown
when ps, apparently run out of _realsetup, is attempting
to read some of the process information. for example, i see

avc:  denied  { getattr } for  pid=2358 exe=/bin/ps path=/1 dev=00:03 
ino=65538
   scontext=system_u:system_r:ipsec_t
   tcontext=system_u:system_r:init_t
   tclass=dir
avc:  denied  { search } for  pid=2358 exe=/bin/ps path=/1 dev=00:03 
ino=65538
   scontext=system_u:system_r:ipsec_t
   tcontext=system_u:system_r:init_t
   tclass=dir
avc:  denied  { read } for  pid=2358 exe=/bin/ps path=/1/stat dev=00:03 
ino=65547
   scontext=system_u:system_r:ipsec_t
   tcontext=system_u:system_r:init_t
   tclass=file

and this repeats for a few other processes with different
tcontexts (e.g., kernel_t and pump_t). running ps (/bin/ps
and /usr/local/selinux/bin/ps) as a user from a shell doesn't
have this problem, and i don't understand the the difference.
before the changes mentioned above, this shutdown behavior
wasn't happening.

i'd appreciate suggestions as to how to address this behavior
at shutdown.

i'd be happy to share the changed/new policy files when i
have them working (or earlier if anybody so desires).

-paul


--
You have received this message because you are subscribed to the selinux 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: use of ps in ipsec shutdown

[Westerman, Mark]

What can try to do is to add

# denials when ps tries to search /proc. Do not audit these denials.
auditdeny ipsec_t domain:dir ~r_dir_perms;
auditdent ipsec_t domain:notdevfile_class_set ~r_file_perms;

The rule where modified from the user.te domain.


Mark Westerman.

PS.
I will have to check my orginal implemtation to see if I experence the
same behavior



-----Original Message-----
From: Paul Krumviede [mailto:pwk@acm.org]
Sent: Friday, November 30, 2001 12:45 PM
To: selinux
Subject: use of ps in ipsec shutdown


i've been experimenting with the freeswan-1.91 ipsec implementation
in some of the more recent selinux releases, including the latest 2.4.14
one, and, after making some changes to the supplied ipsec policy,
have come across something i don't yet know how to handle.

i noticed that the supplied policy left some processes in the
initrc_t domain, such as _plutorun and _plutoload. i also noticed
that the ipsec startup script invokes logger, and that whack,
running in the initrc_t domain, was being denied permission
to connect to the socket set up by pluto. so i labeled the
/usr/local/sbin/ipsec script, whack, _plutoload, _plutoread
and whack as ipsec_exec_t types, and allowed ipsec_t
to execute shells, bin_t and sbin_t things (the latter in part
because the default label of things in /usr/local/lib/ipsec
is sbin_t). this seems to have fixed all the things decribed
above (although i'm open to suggestions as to alternative
approaches).

i also noticed that _startklips wanted (limited) access
to /proc/sys/net/ipsec/icmp, so i gave some sysctl
access.

i later noticed a number of avc denials at shutdown
when ps, apparently run out of _realsetup, is attempting
to read some of the process information. for example, i see

avc:  denied  { getattr } for  pid=2358 exe=/bin/ps path=/1 dev=00:03 
ino=65538
   scontext=system_u:system_r:ipsec_t
   tcontext=system_u:system_r:init_t
   tclass=dir
avc:  denied  { search } for  pid=2358 exe=/bin/ps path=/1 dev=00:03 
ino=65538
   scontext=system_u:system_r:ipsec_t
   tcontext=system_u:system_r:init_t
   tclass=dir
avc:  denied  { read } for  pid=2358 exe=/bin/ps path=/1/stat dev=00:03 
ino=65547
   scontext=system_u:system_r:ipsec_t
   tcontext=system_u:system_r:init_t
   tclass=file

and this repeats for a few other processes with different
tcontexts (e.g., kernel_t and pump_t). running ps (/bin/ps
and /usr/local/selinux/bin/ps) as a user from a shell doesn't
have this problem, and i don't understand the the difference.
before the changes mentioned above, this shutdown behavior
wasn't happening.

i'd appreciate suggestions as to how to address this behavior
at shutdown.

i'd be happy to share the changed/new policy files when i
have them working (or earlier if anybody so desires).

-paul


--
You have received this message because you are subscribed to the selinux
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.

--
You have received this message because you are subscribed to the selinux 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: use of ps in ipsec shutdown

[Paul Krumviede]

--On Friday, 30 November, 2001 14:39 -0600 "Westerman, Mark" 
<Mark.Westerman@csoconline.com> wrote:

> What can try to do is to add
>
> # denials when ps tries to search /proc. Do not audit these denials.
> auditdeny ipsec_t domain:dir ~r_dir_perms;
> auditdent ipsec_t domain:notdevfile_class_set ~r_file_perms;
>
> The rule where modified from the user.te domain.

while this would suppress the warnings, what would happen
if one wanted to restart the ipsec stuff, perhaps because of
a config file change, when in enforcing mode? it would seem
that stopping the service would fail (actually, it would look like
it worked, but because _realsetup wouldn't think that pluto is
running, pluto wouldn't be shut down) and i don't know what
would be the result of the subsequent start.

but i hadn't considered that the reason ps "works" when
run by a user is that the denials may not be audited.

> Mark Westerman.
>
> PS.
> I will have to check my orginal implemtation to see if I experence the
> same behavior

until i made the changes to get the various _plotu* processes running
in a domain other than initrc_t, the only avc denials i saw in the log
were the attempts by whack to connect to the socket created by pluto.

> -----Original Message-----
> From: Paul Krumviede [mailto:pwk@acm.org]
> Sent: Friday, November 30, 2001 12:45 PM
> To: selinux
> Subject: use of ps in ipsec shutdown
>
>
> i've been experimenting with the freeswan-1.91 ipsec implementation
> in some of the more recent selinux releases, including the latest 2.4.14
> one, and, after making some changes to the supplied ipsec policy,
> have come across something i don't yet know how to handle.
>
> i noticed that the supplied policy left some processes in the
> initrc_t domain, such as _plutorun and _plutoload. i also noticed
> that the ipsec startup script invokes logger, and that whack,
> running in the initrc_t domain, was being denied permission
> to connect to the socket set up by pluto. so i labeled the
> /usr/local/sbin/ipsec script, whack, _plutoload, _plutoread
> and whack as ipsec_exec_t types, and allowed ipsec_t
> to execute shells, bin_t and sbin_t things (the latter in part
> because the default label of things in /usr/local/lib/ipsec
> is sbin_t). this seems to have fixed all the things decribed
> above (although i'm open to suggestions as to alternative
> approaches).
>
> i also noticed that _startklips wanted (limited) access
> to /proc/sys/net/ipsec/icmp, so i gave some sysctl
> access.
>
> i later noticed a number of avc denials at shutdown
> when ps, apparently run out of _realsetup, is attempting
> to read some of the process information. for example, i see
>
> avc:  denied  { getattr } for  pid=2358 exe=/bin/ps path=/1 dev=00:03
> ino=65538
>    scontext=system_u:system_r:ipsec_t
>    tcontext=system_u:system_r:init_t
>    tclass=dir
> avc:  denied  { search } for  pid=2358 exe=/bin/ps path=/1 dev=00:03
> ino=65538
>    scontext=system_u:system_r:ipsec_t
>    tcontext=system_u:system_r:init_t
>    tclass=dir
> avc:  denied  { read } for  pid=2358 exe=/bin/ps path=/1/stat dev=00:03
> ino=65547
>    scontext=system_u:system_r:ipsec_t
>    tcontext=system_u:system_r:init_t
>    tclass=file
>
> and this repeats for a few other processes with different
> tcontexts (e.g., kernel_t and pump_t). running ps (/bin/ps
> and /usr/local/selinux/bin/ps) as a user from a shell doesn't
> have this problem, and i don't understand the the difference.
> before the changes mentioned above, this shutdown behavior
> wasn't happening.
>
> i'd appreciate suggestions as to how to address this behavior
> at shutdown.
>
> i'd be happy to share the changed/new policy files when i
> have them working (or earlier if anybody so desires).
>
> -paul
>
>
> --
> You have received this message because you are subscribed to the selinux
> 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.
>



--
You have received this message because you are subscribed to the selinux 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: use of ps in ipsec shutdown

[Stephen Smalley]

On Fri, 30 Nov 2001, Paul Krumviede wrote:

> i noticed that the supplied policy left some processes in the
> initrc_t domain, such as _plutorun and _plutoload. i also noticed
> that the ipsec startup script invokes logger, and that whack,
> running in the initrc_t domain, was being denied permission
> to connect to the socket set up by pluto. so i labeled the
> /usr/local/sbin/ipsec script, whack, _plutoload, _plutoread
> and whack as ipsec_exec_t types, and allowed ipsec_t
> to execute shells, bin_t and sbin_t things (the latter in part
> because the default label of things in /usr/local/lib/ipsec
> is sbin_t). this seems to have fixed all the things decribed
> above (although i'm open to suggestions as to alternative
> approaches).

The problem with this approach is that it increases the risk that
malicious code will be able to execute in the ipsec_t domain and
thus gain access to a PF_KEY socket.  The ipsec_t domain should only
be granted execute access to the ipsec_exec_t type, and this type
should only be assigned to code that legitimately needs to access
PF_KEY sockets.  Any other code should be run in a different domain.

> i also noticed that _startklips wanted (limited) access
> to /proc/sys/net/ipsec/icmp, so i gave some sysctl
> access.

We can modify the module to bind a distinct type to /proc/sys/net/ipsec if
desired.

> i later noticed a number of avc denials at shutdown
> when ps, apparently run out of _realsetup, is attempting
> to read some of the process information. for example, i see
>
> avc:  denied  { getattr } for  pid=2358 exe=/bin/ps path=/1 dev=00:03
> ino=65538
>    scontext=system_u:system_r:ipsec_t
>    tcontext=system_u:system_r:init_t
>    tclass=dir

This is probably happening because the script is now running in ipsec_t,
which isn't a good idea anyway.  But this is a common problem when ps
scans /proc, because only a subset of /proc will be accessible to most
domains.  It is ok to deny these accesses, because this process only
truly needs to access the /proc/PID entries for processes within the
ipsec_t domain in order to shut down those processes.  You can suppress
the audit messages via auditdeny rule, as mentioned by Mark.

> i'd be happy to share the changed/new policy files when i
> have them working (or earlier if anybody so desires).

Yes, please do.  But I don't want to grant the ipsec_t domain execute
access to any other types in the example policy.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: use of ps in ipsec shutdown

[Stephen Smalley]

On Fri, 30 Nov 2001, Paul Krumviede wrote:

> while this would suppress the warnings, what would happen
> if one wanted to restart the ipsec stuff, perhaps because of
> a config file change, when in enforcing mode? it would seem
> that stopping the service would fail (actually, it would look like
> it worked, but because _realsetup wouldn't think that pluto is
> running, pluto wouldn't be shut down) and i don't know what
> would be the result of the subsequent start.

As long as _realsetup is running in ipsec_t, it should be able to
see the pluto daemon and kill it.  But I'm wondering if _realsetup
should really run in a separate domain (e.g. ipsec_client_t) that
can see the ipsec_t domain and communicate with it, but cannot directly
access PF_KEY sockets.

--
Stephen D. Smalley, NAI Labs
ssmalley@nai.com




--
You have received this message because you are subscribed to the selinux 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: use of ps in ipsec shutdown

[Paul Krumviede]

--On Monday, 03 December, 2001 09:23 -0500 Stephen Smalley 
<sds@tislabs.com> wrote:

>
> On Fri, 30 Nov 2001, Paul Krumviede wrote:
>
>> i noticed that the supplied policy left some processes in the
>> initrc_t domain, such as _plutorun and _plutoload. i also noticed
>> that the ipsec startup script invokes logger, and that whack,
>> running in the initrc_t domain, was being denied permission
>> to connect to the socket set up by pluto. so i labeled the
>> /usr/local/sbin/ipsec script, whack, _plutoload, _plutoread
>> and whack as ipsec_exec_t types, and allowed ipsec_t
>> to execute shells, bin_t and sbin_t things (the latter in part
>> because the default label of things in /usr/local/lib/ipsec
>> is sbin_t). this seems to have fixed all the things decribed
>> above (although i'm open to suggestions as to alternative
>> approaches).
>
> The problem with this approach is that it increases the risk that
> malicious code will be able to execute in the ipsec_t domain and
> thus gain access to a PF_KEY socket.  The ipsec_t domain should only
> be granted execute access to the ipsec_exec_t type, and this type
> should only be assigned to code that legitimately needs to access
> PF_KEY sockets.  Any other code should be run in a different domain.

what i want to do is partition all of the ipsec-related code, and then
break those things into more specific domains, such as a domain
that can access/manage keying material and a domain that can
access things in the first domain (perhaps an ipsec_client_t as
you suggest in a subsequent messages). i've been thinking of
an ipsec_admin role as well (one of mark's comments in sysadm.te
alludes to this) and then restricing access to some of the ipsec
functions to this role (and to initrc_t).

the first pass at such a partition started when i noticed that i
had processes running in the initrc_t domain.

>> i also noticed that _startklips wanted (limited) access
>> to /proc/sys/net/ipsec/icmp, so i gave some sysctl
>> access.
>
> We can modify the module to bind a distinct type to /proc/sys/net/ipsec if
> desired.

that seems worthwhile.

>> i later noticed a number of avc denials at shutdown
>> when ps, apparently run out of _realsetup, is attempting
>> to read some of the process information. for example, i see
>>
>> avc:  denied  { getattr } for  pid=2358 exe=/bin/ps path=/1 dev=00:03
>> ino=65538
>>    scontext=system_u:system_r:ipsec_t
>>    tcontext=system_u:system_r:init_t
>>    tclass=dir
>
> This is probably happening because the script is now running in ipsec_t,
> which isn't a good idea anyway.  But this is a common problem when ps
> scans /proc, because only a subset of /proc will be accessible to most
> domains.  It is ok to deny these accesses, because this process only
> truly needs to access the /proc/PID entries for processes within the
> ipsec_t domain in order to shut down those processes.  You can suppress
> the audit messages via auditdeny rule, as mentioned by Mark.

yes, for some reason i was thinking that ps would fail. i'll add the
auditdeny rules.

>> i'd be happy to share the changed/new policy files when i
>> have them working (or earlier if anybody so desires).
>
> Yes, please do.  But I don't want to grant the ipsec_t domain execute
> access to any other types in the example policy.

i'll work on refining what i have to reflect a division between things
that actually need to access the PF_KEY socket and those things
that don't need direct access to the socket.

-paul


--
You have received this message because you are subscribed to the selinux 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.