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.From: Westerman, Mark <Mark.Westerman_at_csoconline.com>
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.
--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.From: Stephen Smalley <sds_at_tislabs.com>
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.From: Stephen Smalley <sds_at_tislabs.com>
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.From: Paul Krumviede <pwk_at_acm.org>
--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.
This archive was generated by hypermail 2.2.0 on Wed 11 Jun 2008 - 08:10:54 EDT