From sds at tycho.nsa.gov Fri Sep 1 12:49:37 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 01 Sep 2006 08:49:37 -0400 Subject: [redhat-lspp] Updated NetLabel/CIPSO policy module In-Reply-To: <20060831172029.GC12318@w-m-p.com> References: <20060831013320.GA10404@w-m-p.com> <44F6DCA1.7020900@hp.com> <20060831172029.GC12318@w-m-p.com> Message-ID: <1157114977.26621.68.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-08-31 at 12:20 -0500, Klaus Weidner wrote: > On Thu, Aug 31, 2006 at 08:57:05AM -0400, Paul Moore wrote: > > Klaus Weidner wrote: > > > I was a bit surprised that a "s2-s2" process can connect successfully to > > > a "s3-s3" process, send it data, and select/poll(2) waiting for data. > [...] > > > It works as expected the other way around, the s3 process gets an > > > immediate "connection refused" when trying to connect to the s2 process. > > > > This smells like a policy issue to me. Taking a quick look at the > > reference policy mls constraints (this is from a svn snapshot which is > > probably a month or two old, so it may have changed) I see the following > > constraint (unrelated types removed for clarity): > > It's a bit more complex now: > > # the socket "read" ops (note the check is dominance of the low level) > mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { read getattr listen accept getopt recvfrom recv_msg } > (( l1 dom l2 ) or > (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or > ( t1 == mlsnetread )); > > # the socket "write" ops > mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { write setattr relabelfrom connect setopt shutdown } > ((( l1 dom l2 ) and ( l1 domby h2 )) or > (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or > ( t1 == mlsnetwrite )); > > Based on that policy, I'd expect the constraint on "connect" to prevent a > l1=s2,h1=s2 process from connecting to a l2=s2,h2=s2 port. Am I > misunderstanding something or is the check mixed up? connect is a process-to-socket check handled entirely in the socket layer, i.e. can process A initiate a connection via socket S (where S is its local endpoint, not the peer). It isn't a check on the peer. recv_msg is likely the one of interest to you for NetLabel. You could separate out the mls constraint on tcp_socket to require equivalence for recv_msg in that case (overloading with old net controls is bad though). If secid reconciliation progresses fully and secmark is enabled, then packet recv would be the check of interest. -- Stephen Smalley National Security Agency From paul.moore at hp.com Fri Sep 1 12:55:43 2006 From: paul.moore at hp.com (Paul Moore) Date: Fri, 01 Sep 2006 08:55:43 -0400 Subject: [redhat-lspp] Updated NetLabel/CIPSO policy module In-Reply-To: <1157114977.26621.68.camel@moss-spartans.epoch.ncsc.mil> References: <20060831013320.GA10404@w-m-p.com> <44F6DCA1.7020900@hp.com> <20060831172029.GC12318@w-m-p.com> <1157114977.26621.68.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <44F82DCF.901@hp.com> Stephen Smalley wrote: > On Thu, 2006-08-31 at 12:20 -0500, Klaus Weidner wrote: >>On Thu, Aug 31, 2006 at 08:57:05AM -0400, Paul Moore wrote: >>>Klaus Weidner wrote: >>> >>>>I was a bit surprised that a "s2-s2" process can connect successfully to >>>>a "s3-s3" process, send it data, and select/poll(2) waiting for data. >> >>[...] >> >>>>It works as expected the other way around, the s3 process gets an >>>>immediate "connection refused" when trying to connect to the s2 process. >>> >>>This smells like a policy issue to me. Taking a quick look at the >>>reference policy mls constraints (this is from a svn snapshot which is >>>probably a month or two old, so it may have changed) I see the following >>>constraint (unrelated types removed for clarity): >> >>It's a bit more complex now: >> >># the socket "read" ops (note the check is dominance of the low level) >>mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { read getattr listen accept getopt recvfrom recv_msg } >> (( l1 dom l2 ) or >> (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or >> ( t1 == mlsnetread )); >> >># the socket "write" ops >>mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { write setattr relabelfrom connect setopt shutdown } >> ((( l1 dom l2 ) and ( l1 domby h2 )) or >> (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or >> ( t1 == mlsnetwrite )); >> >>Based on that policy, I'd expect the constraint on "connect" to prevent a >>l1=s2,h1=s2 process from connecting to a l2=s2,h2=s2 port. Am I >>misunderstanding something or is the check mixed up? > > connect is a process-to-socket check handled entirely in the socket > layer, i.e. can process A initiate a connection via socket S (where S is > its local endpoint, not the peer). It isn't a check on the peer. > > recv_msg is likely the one of interest to you for NetLabel. You could > separate out the mls constraint on tcp_socket to require equivalence for > recv_msg in that case (overloading with old net controls is bad though). I know we've talked about this before and decided to stick with using recv_msg ... does it make sense to introduce a new permission, say nlbl_recv? Or do we just not care because of the secid reconciliation work? > If secid reconciliation progresses fully and secmark is enabled, then > packet recv would be the check of interest. -- paul moore linux security @ hp From sds at tycho.nsa.gov Fri Sep 1 13:27:18 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 01 Sep 2006 09:27:18 -0400 Subject: [redhat-lspp] Updated NetLabel/CIPSO policy module In-Reply-To: <44F82DCF.901@hp.com> References: <20060831013320.GA10404@w-m-p.com> <44F6DCA1.7020900@hp.com> <20060831172029.GC12318@w-m-p.com> <1157114977.26621.68.camel@moss-spartans.epoch.ncsc.mil> <44F82DCF.901@hp.com> Message-ID: <1157117238.26621.78.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-09-01 at 08:55 -0400, Paul Moore wrote: > Stephen Smalley wrote: > > On Thu, 2006-08-31 at 12:20 -0500, Klaus Weidner wrote: > >>On Thu, Aug 31, 2006 at 08:57:05AM -0400, Paul Moore wrote: > >>>Klaus Weidner wrote: > >>> > >>>>I was a bit surprised that a "s2-s2" process can connect successfully to > >>>>a "s3-s3" process, send it data, and select/poll(2) waiting for data. > >> > >>[...] > >> > >>>>It works as expected the other way around, the s3 process gets an > >>>>immediate "connection refused" when trying to connect to the s2 process. > >>> > >>>This smells like a policy issue to me. Taking a quick look at the > >>>reference policy mls constraints (this is from a svn snapshot which is > >>>probably a month or two old, so it may have changed) I see the following > >>>constraint (unrelated types removed for clarity): > >> > >>It's a bit more complex now: > >> > >># the socket "read" ops (note the check is dominance of the low level) > >>mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { read getattr listen accept getopt recvfrom recv_msg } > >> (( l1 dom l2 ) or > >> (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or > >> ( t1 == mlsnetread )); > >> > >># the socket "write" ops > >>mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { write setattr relabelfrom connect setopt shutdown } > >> ((( l1 dom l2 ) and ( l1 domby h2 )) or > >> (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or > >> ( t1 == mlsnetwrite )); > >> > >>Based on that policy, I'd expect the constraint on "connect" to prevent a > >>l1=s2,h1=s2 process from connecting to a l2=s2,h2=s2 port. Am I > >>misunderstanding something or is the check mixed up? > > > > connect is a process-to-socket check handled entirely in the socket > > layer, i.e. can process A initiate a connection via socket S (where S is > > its local endpoint, not the peer). It isn't a check on the peer. > > > > recv_msg is likely the one of interest to you for NetLabel. You could > > separate out the mls constraint on tcp_socket to require equivalence for > > recv_msg in that case (overloading with old net controls is bad though). > > I know we've talked about this before and decided to stick with using > recv_msg ... does it make sense to introduce a new permission, say > nlbl_recv? Or do we just not care because of the secid reconciliation work? Hmmm...I thought that my guidance had been to use one of the obsoleted permissions in the socket class that was no longer in use by the kernel, like recvfrom (in common socket, different from association recvfrom). Of course, if secmark is enabled, then recv_msg is likewise "obsoleted". -- Stephen Smalley National Security Agency From paul.moore at hp.com Fri Sep 1 13:46:14 2006 From: paul.moore at hp.com (Paul Moore) Date: Fri, 01 Sep 2006 09:46:14 -0400 Subject: [redhat-lspp] Updated NetLabel/CIPSO policy module In-Reply-To: <1157117238.26621.78.camel@moss-spartans.epoch.ncsc.mil> References: <20060831013320.GA10404@w-m-p.com> <44F6DCA1.7020900@hp.com> <20060831172029.GC12318@w-m-p.com> <1157114977.26621.68.camel@moss-spartans.epoch.ncsc.mil> <44F82DCF.901@hp.com> <1157117238.26621.78.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <44F839A6.4090305@hp.com> Stephen Smalley wrote: > On Fri, 2006-09-01 at 08:55 -0400, Paul Moore wrote: > >>Stephen Smalley wrote: >> >>>On Thu, 2006-08-31 at 12:20 -0500, Klaus Weidner wrote: >>> >>>>On Thu, Aug 31, 2006 at 08:57:05AM -0400, Paul Moore wrote: >>>> >>>>>Klaus Weidner wrote: >>>>> >>>>> >>>>>>I was a bit surprised that a "s2-s2" process can connect successfully to >>>>>>a "s3-s3" process, send it data, and select/poll(2) waiting for data. >>>> >>>>[...] >>>> >>>> >>>>>>It works as expected the other way around, the s3 process gets an >>>>>>immediate "connection refused" when trying to connect to the s2 process. >>>>> >>>>>This smells like a policy issue to me. Taking a quick look at the >>>>>reference policy mls constraints (this is from a svn snapshot which is >>>>>probably a month or two old, so it may have changed) I see the following >>>>>constraint (unrelated types removed for clarity): >>>> >>>>It's a bit more complex now: >>>> >>>># the socket "read" ops (note the check is dominance of the low level) >>>>mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { read getattr listen accept getopt recvfrom recv_msg } >>>> (( l1 dom l2 ) or >>>> (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or >>>> ( t1 == mlsnetread )); >>>> >>>># the socket "write" ops >>>>mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { write setattr relabelfrom connect setopt shutdown } >>>> ((( l1 dom l2 ) and ( l1 domby h2 )) or >>>> (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or >>>> ( t1 == mlsnetwrite )); >>>> >>>>Based on that policy, I'd expect the constraint on "connect" to prevent a >>>>l1=s2,h1=s2 process from connecting to a l2=s2,h2=s2 port. Am I >>>>misunderstanding something or is the check mixed up? >>> >>>connect is a process-to-socket check handled entirely in the socket >>>layer, i.e. can process A initiate a connection via socket S (where S is >>>its local endpoint, not the peer). It isn't a check on the peer. >>> >>>recv_msg is likely the one of interest to you for NetLabel. You could >>>separate out the mls constraint on tcp_socket to require equivalence for >>>recv_msg in that case (overloading with old net controls is bad though). >> >>I know we've talked about this before and decided to stick with using >>recv_msg ... does it make sense to introduce a new permission, say >>nlbl_recv? Or do we just not care because of the secid reconciliation work? > > > Hmmm...I thought that my guidance had been to use one of the obsoleted > permissions in the socket class that was no longer in use by the kernel, > like recvfrom (in common socket, different from association recvfrom). You could very well be right (I'd have to check the archives). I suspect I just got it confused with recv_msg. My mistake, but come on guys, you couldn't have come up with some better more easily distinguished permission names so people like me aren't as easily confused? ;) Unless I hear any objections I'll see about making the change and submitting it. > Of course, if secmark is enabled, then recv_msg is likewise "obsoleted". -- paul moore linux security @ hp From vyekkirala at TrustedCS.com Fri Sep 1 16:02:03 2006 From: vyekkirala at TrustedCS.com (Venkat Yekkirala) Date: Fri, 1 Sep 2006 12:02:03 -0400 Subject: [redhat-lspp] Updated NetLabel/CIPSO policy module Message-ID: <36282A1733C57546BE392885C061859201512D4B@chaos.tcs.tcs-sec.com> > > Of course, if secmark is enabled, then recv_msg is likewise > "obsoleted". In the secmark case, the following is how the mls constraint would look like (causing the connection request to fail in the "unprivileged" case): # the packet "recv" op (implicit single level) mlsconstrain packet recv (( l1 eq l2 ) or (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or ( t1 == mlsnetread )); From ltcgcw at us.ibm.com Fri Sep 1 22:25:00 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Fri, 1 Sep 2006 17:25:00 -0500 Subject: [redhat-lspp] [Update] No Open LSPP Development Telecon Mon., Sept. 4 Message-ID: <20060901222500.GA6588@us.ibm.com> Monday, Sept. 4 is Labor Day in the US. There will be no meeting next week. Our next meeting will be Monday, Sept. 11. IBM hosts a telecon every Monday at 20:00 UTC to discuss the development issues surrounding Linux LSPP certification. The call is open to all who have something to bring to the effort. If you would like to participate and are not already an attendee, please reply directly to me with your contact information. I will respond with an invitation. Please note that the number of attendees may be limited by our call center's restrictions on maximum lines per conference. -- George Wilson IBM Linux Technology Center From cpebenito at tresys.com Fri Sep 1 13:35:11 2006 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Fri, 01 Sep 2006 09:35:11 -0400 Subject: [redhat-lspp] Updated NetLabel/CIPSO policy module In-Reply-To: <1157117238.26621.78.camel@moss-spartans.epoch.ncsc.mil> References: <20060831013320.GA10404@w-m-p.com> <44F6DCA1.7020900@hp.com> <20060831172029.GC12318@w-m-p.com> <1157114977.26621.68.camel@moss-spartans.epoch.ncsc.mil> <44F82DCF.901@hp.com> <1157117238.26621.78.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1157117711.3199.100.camel@sgc.columbia.tresys.com> On Fri, 2006-09-01 at 09:27 -0400, Stephen Smalley wrote: > On Fri, 2006-09-01 at 08:55 -0400, Paul Moore wrote: > > Stephen Smalley wrote: > > > On Thu, 2006-08-31 at 12:20 -0500, Klaus Weidner wrote: > > >>On Thu, Aug 31, 2006 at 08:57:05AM -0400, Paul Moore wrote: > > >>>Klaus Weidner wrote: > > >>> > > >>>>I was a bit surprised that a "s2-s2" process can connect successfully to > > >>>>a "s3-s3" process, send it data, and select/poll(2) waiting for data. > > >> > > >>[...] > > >> > > >>>>It works as expected the other way around, the s3 process gets an > > >>>>immediate "connection refused" when trying to connect to the s2 process. > > >>> > > >>>This smells like a policy issue to me. Taking a quick look at the > > >>>reference policy mls constraints (this is from a svn snapshot which is > > >>>probably a month or two old, so it may have changed) I see the following > > >>>constraint (unrelated types removed for clarity): > > >> > > >>It's a bit more complex now: > > >> > > >># the socket "read" ops (note the check is dominance of the low level) > > >>mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { read getattr listen accept getopt recvfrom recv_msg } > > >> (( l1 dom l2 ) or > > >> (( t1 == mlsnetreadtoclr ) and ( h1 dom l2 )) or > > >> ( t1 == mlsnetread )); > > >> > > >># the socket "write" ops > > >>mlsconstrain { socket tcp_socket udp_socket rawip_socket netlink_socket packet_socket key_socket unix_stream_socket unix_dgram_socket netlink_route_socket netlink_firewall_socket netlink_tcpdiag_socket netlink_nflog_socket netlink_xfrm_socket netlink_selinux_socket netlink_audit_socket netlink_ip6fw_socket netlink_dnrt_socket } { write setattr relabelfrom connect setopt shutdown } > > >> ((( l1 dom l2 ) and ( l1 domby h2 )) or > > >> (( t1 == mlsnetwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or > > >> ( t1 == mlsnetwrite )); > > >> > > >>Based on that policy, I'd expect the constraint on "connect" to prevent a > > >>l1=s2,h1=s2 process from connecting to a l2=s2,h2=s2 port. Am I > > >>misunderstanding something or is the check mixed up? > > > > > > connect is a process-to-socket check handled entirely in the socket > > > layer, i.e. can process A initiate a connection via socket S (where S is > > > its local endpoint, not the peer). It isn't a check on the peer. > > > > > > recv_msg is likely the one of interest to you for NetLabel. You could > > > separate out the mls constraint on tcp_socket to require equivalence for > > > recv_msg in that case (overloading with old net controls is bad though). > > > > I know we've talked about this before and decided to stick with using > > recv_msg ... does it make sense to introduce a new permission, say > > nlbl_recv? Or do we just not care because of the secid reconciliation work? > > Hmmm...I thought that my guidance had been to use one of the obsoleted > permissions in the socket class that was no longer in use by the kernel, > like recvfrom (in common socket, different from association recvfrom). > Of course, if secmark is enabled, then recv_msg is likewise "obsoleted". I suggest recvfrom, as it has been unused since 2003, whereas recv_msg is just starting on its way out. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From jantill at redhat.com Mon Sep 4 22:33:43 2006 From: jantill at redhat.com (James Antill) Date: Mon, 04 Sep 2006 18:33:43 -0400 Subject: [redhat-lspp] Netlabel tools in Fedora development Message-ID: <1157409223.6269.5.camel@code.and.org> Just a note to let you know that netlabel_tools is now in the Fedora Development repository (aka. rawhide). If anyone finds bugs, feel free to put them in the Fedora Bugzilla. Thanks. -- James Antill -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From thompsmc at us.ibm.com Thu Sep 7 21:34:34 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Thu, 07 Sep 2006 16:34:34 -0500 Subject: [redhat-lspp] MLS Policy (rawhide) Message-ID: <4500906A.3000502@us.ibm.com> Hey all, It seems that ssh is unable to add entries to known_hosts for the root user as sysadm_t. Is this a known issue? And if so, who can add entries to /root/.ssh/known_hosts ? Thanks, Mike From thompsmc at us.ibm.com Thu Sep 7 21:51:56 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Thu, 07 Sep 2006 16:51:56 -0500 Subject: [redhat-lspp] Re: MLS Policy (rawhide) In-Reply-To: <4500906A.3000502@us.ibm.com> References: <4500906A.3000502@us.ibm.com> Message-ID: <4500947C.6090400@us.ibm.com> Michael C Thompson wrote: > Hey all, > > It seems that ssh is unable to add entries to known_hosts for the root > user as sysadm_t. Is this a known issue? And if so, who can add entries > to /root/.ssh/known_hosts ? I think I should point out that this isn't as the user, but when executing ssh as root. From dwalsh at redhat.com Fri Sep 8 18:08:49 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 08 Sep 2006 14:08:49 -0400 Subject: [redhat-lspp] Re: MLS Policy (rawhide) In-Reply-To: <4500906A.3000502@us.ibm.com> References: <4500906A.3000502@us.ibm.com> Message-ID: <4501B1B1.4020103@redhat.com> Michael C Thompson wrote: > Hey all, > > It seems that ssh is unable to add entries to known_hosts for the root > user as sysadm_t. Is this a known issue? And if so, who can add > entries to /root/.ssh/known_hosts ? > > Thanks, > Mike > This works for me. How is the file labeled? From dwalsh at redhat.com Fri Sep 8 18:56:11 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 08 Sep 2006 14:56:11 -0400 Subject: [redhat-lspp] This looks like cron is running jobs in the wrong context. Message-ID: <4501BCCB.405@redhat.com> allow user_crond_t apmd_log_t:file getattr; allow user_crond_t cupsd_log_t:dir read; allow user_crond_t devlog_t:sock_file write; allow user_crond_t httpd_log_t:dir read; allow user_crond_t logwatch_cache_t:dir read; allow user_crond_t man_t:dir { getattr read search }; allow user_crond_t print_spool_t:dir search; allow user_crond_t rpm_log_t:file { getattr write }; allow user_crond_t sendmail_exec_t:file entrypoint; allow user_crond_t tmp_t:dir { read write }; allow user_crond_t var_lib_t:dir { getattr search }; allow user_crond_t var_lock_t:dir search; allow user_crond_t var_log_t:dir read; allow user_crond_t var_log_t:file getattr; These should be running in system_crond_t? This is logwatch creating most of these. Do you think the latest patch is causing this? From latten at austin.ibm.com Fri Sep 8 19:09:38 2006 From: latten at austin.ibm.com (Joy Latten) Date: Fri, 8 Sep 2006 14:09:38 -0500 Subject: [redhat-lspp] Which role to configure IPSec? Message-ID: <200609081909.k88J9cG4013361@faith.austin.ibm.com> I am running rawhide which I installed on Sept 5, and it has selinux-policy-mls-2.3.11-1. I logged in and did a newrole -r sysadm_r, so my context is root:sysadm_r:sysadm_t:SystemLow-SystemHigh. I wasn't able to configure nor run IPSec in enforcing. I am wondering is sysadm_r the correct role to configure IPSec? I also am just trying to run plain IPSec, with no labels, thus it is taking the default of unlabeled_t. So far, audit.log says I need the following rules to configure IPSec with the setkey command and then do a ping to test the connection. allow unlabeled_t self:association { polmatch sendto recvfrom }; allow ping_t unlabeled_t:association polmatch; allow sysadm_t self:key_socket { create read setopt write }; The first 2 rules appear to be generally applicable. The first one I added to kernel.te because I didn't know where else to place it. For the second rule, I added "polmatch" to kernel_sendrecv_unlabeled_association interface so that other networking utilities would also acquire the permission. Again, I don't really know if this is the best place to put it. But the last one is particular to sysadm_t or whoever runs the setkey command which is used to configure IPSec. I also tried secadm_r and got similar complaints. I guess what I would like to know is whether sysadm_r the correct role to configure ipsec? Regards, Joy From thompsmc at us.ibm.com Fri Sep 8 19:28:38 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Fri, 08 Sep 2006 14:28:38 -0500 Subject: [redhat-lspp] Re: MLS Policy (rawhide) In-Reply-To: <4501B1B1.4020103@redhat.com> References: <4500906A.3000502@us.ibm.com> <4501B1B1.4020103@redhat.com> Message-ID: <4501C466.7060309@us.ibm.com> Daniel J Walsh wrote: > Michael C Thompson wrote: >> Hey all, >> >> It seems that ssh is unable to add entries to known_hosts for the root >> user as sysadm_t. Is this a known issue? And if so, who can add >> entries to /root/.ssh/known_hosts ? >> >> Thanks, >> Mike >> > This works for me. How is the file labeled? # ls -alZ /root/.ssh drwx------ root root root:object_r:user_home_ssh_t:SystemLow . drwxr-x--- root root root:object_r:sysadm_home_dir_t:SystemLow-SystemHigh .. -rw------- root root root:object_r:bin_t:SystemLow id_rsa -rw-r--r-- root root root:object_r:bin_t:SystemLow id_rsa.pub -rw-r--r-- root root root:object_r:user_home_ssh_t:SystemLow known_hosts From sds at tycho.nsa.gov Fri Sep 8 19:40:30 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 08 Sep 2006 15:40:30 -0400 Subject: [redhat-lspp] Re: MLS Policy (rawhide) In-Reply-To: <4501C466.7060309@us.ibm.com> References: <4500906A.3000502@us.ibm.com> <4501B1B1.4020103@redhat.com> <4501C466.7060309@us.ibm.com> Message-ID: <1157744430.31695.210.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-09-08 at 14:28 -0500, Michael C Thompson wrote: > Daniel J Walsh wrote: > > Michael C Thompson wrote: > >> Hey all, > >> > >> It seems that ssh is unable to add entries to known_hosts for the root > >> user as sysadm_t. Is this a known issue? And if so, who can add > >> entries to /root/.ssh/known_hosts ? > >> > >> Thanks, > >> Mike > >> > > This works for me. How is the file labeled? > > # ls -alZ /root/.ssh > drwx------ root root root:object_r:user_home_ssh_t:SystemLow . > drwxr-x--- root root > root:object_r:sysadm_home_dir_t:SystemLow-SystemHigh .. > -rw------- root root root:object_r:bin_t:SystemLow id_rsa > -rw-r--r-- root root root:object_r:bin_t:SystemLow id_rsa.pub > -rw-r--r-- root root root:object_r:user_home_ssh_t:SystemLow known_hosts /sbin/restorecon -R /root/.ssh -- Stephen Smalley National Security Agency From thompsmc at us.ibm.com Fri Sep 8 19:47:54 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Fri, 08 Sep 2006 14:47:54 -0500 Subject: [redhat-lspp] Re: MLS Policy (rawhide) In-Reply-To: <1157744430.31695.210.camel@moss-spartans.epoch.ncsc.mil> References: <4500906A.3000502@us.ibm.com> <4501B1B1.4020103@redhat.com> <4501C466.7060309@us.ibm.com> <1157744430.31695.210.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4501C8EA.7020105@us.ibm.com> Stephen Smalley wrote: > On Fri, 2006-09-08 at 14:28 -0500, Michael C Thompson wrote: >> Daniel J Walsh wrote: >>> Michael C Thompson wrote: >>>> Hey all, >>>> >>>> It seems that ssh is unable to add entries to known_hosts for the root >>>> user as sysadm_t. Is this a known issue? And if so, who can add >>>> entries to /root/.ssh/known_hosts ? >>>> >>>> Thanks, >>>> Mike >>>> >>> This works for me. How is the file labeled? >> # ls -alZ /root/.ssh >> drwx------ root root root:object_r:user_home_ssh_t:SystemLow . >> drwxr-x--- root root >> root:object_r:sysadm_home_dir_t:SystemLow-SystemHigh .. >> -rw------- root root root:object_r:bin_t:SystemLow id_rsa >> -rw-r--r-- root root root:object_r:bin_t:SystemLow id_rsa.pub >> -rw-r--r-- root root root:object_r:user_home_ssh_t:SystemLow known_hosts > > /sbin/restorecon -R /root/.ssh I have relabeled this system numerous times with touch /.autorelabel... why wasn't this picked up? Mike From sds at tycho.nsa.gov Fri Sep 8 20:03:33 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 08 Sep 2006 16:03:33 -0400 Subject: [redhat-lspp] Re: MLS Policy (rawhide) In-Reply-To: <4501C8EA.7020105@us.ibm.com> References: <4500906A.3000502@us.ibm.com> <4501B1B1.4020103@redhat.com> <4501C466.7060309@us.ibm.com> <1157744430.31695.210.camel@moss-spartans.epoch.ncsc.mil> <4501C8EA.7020105@us.ibm.com> Message-ID: <1157745813.31695.218.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-09-08 at 14:47 -0500, Michael C Thompson wrote: > Stephen Smalley wrote: > > On Fri, 2006-09-08 at 14:28 -0500, Michael C Thompson wrote: > >> Daniel J Walsh wrote: > >>> Michael C Thompson wrote: > >>>> Hey all, > >>>> > >>>> It seems that ssh is unable to add entries to known_hosts for the root > >>>> user as sysadm_t. Is this a known issue? And if so, who can add > >>>> entries to /root/.ssh/known_hosts ? > >>>> > >>>> Thanks, > >>>> Mike > >>>> > >>> This works for me. How is the file labeled? > >> # ls -alZ /root/.ssh > >> drwx------ root root root:object_r:user_home_ssh_t:SystemLow . > >> drwxr-x--- root root > >> root:object_r:sysadm_home_dir_t:SystemLow-SystemHigh .. > >> -rw------- root root root:object_r:bin_t:SystemLow id_rsa > >> -rw-r--r-- root root root:object_r:bin_t:SystemLow id_rsa.pub > >> -rw-r--r-- root root root:object_r:user_home_ssh_t:SystemLow known_hosts > > > > /sbin/restorecon -R /root/.ssh > > I have relabeled this system numerous times with touch /.autorelabel... > why wasn't this picked up? Not sure, not a big fan of autorelabeling myself. Is /home on a separate partition? Would it be mounted when the relabel runs from rc.sysinit? -- Stephen Smalley National Security Agency From thompsmc at us.ibm.com Fri Sep 8 20:07:50 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Fri, 08 Sep 2006 15:07:50 -0500 Subject: [redhat-lspp] Re: MLS Policy (rawhide) In-Reply-To: <1157745813.31695.218.camel@moss-spartans.epoch.ncsc.mil> References: <4500906A.3000502@us.ibm.com> <4501B1B1.4020103@redhat.com> <4501C466.7060309@us.ibm.com> <1157744430.31695.210.camel@moss-spartans.epoch.ncsc.mil> <4501C8EA.7020105@us.ibm.com> <1157745813.31695.218.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4501CD96.8020508@us.ibm.com> Stephen Smalley wrote: > On Fri, 2006-09-08 at 14:47 -0500, Michael C Thompson wrote: >> Stephen Smalley wrote: >>> On Fri, 2006-09-08 at 14:28 -0500, Michael C Thompson wrote: >>>> Daniel J Walsh wrote: >>>>> Michael C Thompson wrote: >>>>>> Hey all, >>>>>> >>>>>> It seems that ssh is unable to add entries to known_hosts for the root >>>>>> user as sysadm_t. Is this a known issue? And if so, who can add >>>>>> entries to /root/.ssh/known_hosts ? >>>>>> >>>>>> Thanks, >>>>>> Mike >>>>>> >>>>> This works for me. How is the file labeled? >>>> # ls -alZ /root/.ssh >>>> drwx------ root root root:object_r:user_home_ssh_t:SystemLow . >>>> drwxr-x--- root root >>>> root:object_r:sysadm_home_dir_t:SystemLow-SystemHigh .. >>>> -rw------- root root root:object_r:bin_t:SystemLow id_rsa >>>> -rw-r--r-- root root root:object_r:bin_t:SystemLow id_rsa.pub >>>> -rw-r--r-- root root root:object_r:user_home_ssh_t:SystemLow known_hosts >>> /sbin/restorecon -R /root/.ssh >> I have relabeled this system numerous times with touch /.autorelabel... >> why wasn't this picked up? > > Not sure, not a big fan of autorelabeling myself. Me either, not sure how it got some messed up though. > Is /home on a > separate partition? Would it be mounted when the relabel runs from > rc.sysinit? Well, it wasn't in /home, but even then that isn't the case. But it works now, so thanks Stephen :) Mike From janak at us.ibm.com Fri Sep 8 21:20:53 2006 From: janak at us.ibm.com (Janak Desai) Date: Fri, 08 Sep 2006 17:20:53 -0400 Subject: [redhat-lspp] Re: This looks like cron is running jobs in the wrong context. In-Reply-To: <4501BCCB.405@redhat.com> References: <4501BCCB.405@redhat.com> Message-ID: <4501DEB5.9090903@us.ibm.com> Daniel J Walsh wrote: > > allow user_crond_t apmd_log_t:file getattr; > allow user_crond_t cupsd_log_t:dir read; > allow user_crond_t devlog_t:sock_file write; > allow user_crond_t httpd_log_t:dir read; > allow user_crond_t logwatch_cache_t:dir read; > allow user_crond_t man_t:dir { getattr read search }; > allow user_crond_t print_spool_t:dir search; > allow user_crond_t rpm_log_t:file { getattr write }; > allow user_crond_t sendmail_exec_t:file entrypoint; > allow user_crond_t tmp_t:dir { read write }; > allow user_crond_t var_lib_t:dir { getattr search }; > allow user_crond_t var_lock_t:dir search; > allow user_crond_t var_log_t:dir read; > allow user_crond_t var_log_t:file getattr; > > These should be running in system_crond_t? This is logwatch creating > most of these. Do > you think the latest patch is causing this? > Latest patch to the policy or cron? Jason's patch to cron gets context from the job, checks if the cron daemon can switch into that context, and then calls setexeccon with that context. -Janak From ltcgcw at us.ibm.com Fri Sep 8 21:32:34 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Fri, 8 Sep 2006 16:32:34 -0500 Subject: [redhat-lspp] [Reminder] Open LSPP Development Telecon Mon., Sept. 11 Message-ID: <20060908213234.GA11925@us.ibm.com> You are invited to the LSPP development telecon hosted by IBM. If you have items for the agenda, please send them to me or bring them up at the beginning of the meeting. I will send a reminder note with revised agenda each Friday and post a general notification to the redhat-lspp list. Please feel free to contact me directly with any issues related to this meeting. Rules: WE MUST NOT DISCUSS PROPRIETARY INFORMATION. This call is open to anyone who wants to participate actively. The number of lines per conference may limit the number of callers. We need to follow the agenda pretty closely. Please mute/unmute your line with *6 if we have line noise. Time: 20:00 UTC every Monday, next meeting September 11 Location: 902/5A-011 Call-in (Toll Free): 1-877-422-0032 International (Toll): 1-314-655-1408 Tie-line dial-in: 422-0032 Passcode: 664287# 15:00 CDT / 16:00 EDT / 20:00 UTC Tentative Agenda: Kernel / Rawhide update SELinux base update MLS policy issues Audit userspace Print CIPSO IPsec xinetd ipsec-tools: SPD dump and racoon base + MLS Single-user mode Self tests VFS polyinstantiation Cron, tmpwatch, mail, etc. Bugs / remaining tasks Final cutoff date -- George Wilson IBM Linux Technology Center From txtoth at gmail.com Fri Sep 8 21:37:36 2006 From: txtoth at gmail.com (Ted X Toth) Date: Fri, 08 Sep 2006 16:37:36 -0500 Subject: [redhat-lspp] SO_PEERCRED for IPsec Message-ID: <4501E2A0.3070602@gmail.com> Would others find this as useful as we would? I'm not sure what all authentication mechanisms can be used for IPsec but when a PKI cert is used the certs DN could be returned. Ted From dwalsh at redhat.com Mon Sep 11 15:34:17 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 11 Sep 2006 11:34:17 -0400 Subject: [redhat-lspp] Re: This looks like cron is running jobs in the wrong context. In-Reply-To: <4501DEB5.9090903@us.ibm.com> References: <4501BCCB.405@redhat.com> <4501DEB5.9090903@us.ibm.com> Message-ID: <450581F9.5000606@redhat.com> Janak Desai wrote: > Daniel J Walsh wrote: > >> >> allow user_crond_t apmd_log_t:file getattr; >> allow user_crond_t cupsd_log_t:dir read; >> allow user_crond_t devlog_t:sock_file write; >> allow user_crond_t httpd_log_t:dir read; >> allow user_crond_t logwatch_cache_t:dir read; >> allow user_crond_t man_t:dir { getattr read search }; >> allow user_crond_t print_spool_t:dir search; >> allow user_crond_t rpm_log_t:file { getattr write }; >> allow user_crond_t sendmail_exec_t:file entrypoint; >> allow user_crond_t tmp_t:dir { read write }; >> allow user_crond_t var_lib_t:dir { getattr search }; >> allow user_crond_t var_lock_t:dir search; >> allow user_crond_t var_log_t:dir read; >> allow user_crond_t var_log_t:file getattr; >> >> These should be running in system_crond_t? This is logwatch >> creating most of these. Do >> you think the latest patch is causing this? >> > > Latest patch to the policy or cron? Jason's patch to > cron gets context from the job, checks if the cron > daemon can switch into that context, and then calls > setexeccon with that context. > > -Janak > But the idea was to run system cron jobs as system_crond_t as opposed to user cron jobs. So with this patch, it seems to be running system cron jobs with user_crond_t. (/etc/crond.d, /etc/cron.daily ...) From amy.griffis at hp.com Mon Sep 11 18:49:03 2006 From: amy.griffis at hp.com (Amy Griffis) Date: Mon, 11 Sep 2006 14:49:03 -0400 Subject: [redhat-lspp] Re: inotify_rm_watch behavior In-Reply-To: <200609111505.24567.efleury@br.ibm.com> References: <200609111505.24567.efleury@br.ibm.com> Message-ID: <20060911184903.GA32335@fc.hp.com> Eduardo Madeira Fleury wrote: [Mon Sep 11 2006, 02:05:24PM EDT] > I'm doing some tests and currently inotify_rm_watch is not performing any > permission checks, i.e., an ordinary user can remove a watch set by root on a > file with root:root 400 permission. > > Is this the expected behavior? Seems like neither MAC nor MLS checks are being > done. Yes. As I understand it, an inotify watch is not a data object, and so does not require DAC or MAC checks. Amy From sds at tycho.nsa.gov Mon Sep 11 19:15:59 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 11 Sep 2006 15:15:59 -0400 Subject: [redhat-lspp] Re: inotify_rm_watch behavior In-Reply-To: <20060911184903.GA32335@fc.hp.com> References: <200609111505.24567.efleury@br.ibm.com> <20060911184903.GA32335@fc.hp.com> Message-ID: <1158002159.5960.118.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-09-11 at 14:49 -0400, Amy Griffis wrote: > Eduardo Madeira Fleury wrote: [Mon Sep 11 2006, 02:05:24PM EDT] > > I'm doing some tests and currently inotify_rm_watch is not performing any > > permission checks, i.e., an ordinary user can remove a watch set by root on a > > file with root:root 400 permission. > > > > Is this the expected behavior? Seems like neither MAC nor MLS checks are being > > done. > > Yes. As I understand it, an inotify watch is not a data object, and > so does not require DAC or MAC checks. Not sure I follow the rationale for MAC. Process in security context C1 creates an inotify instance, adds some watches to files/directories it can read (read permission checked between C1 and file context upon inotify_add_watch), provides the instance descriptor to a process in security context C2 via execve inheritance or local IPC. Process in security context C2 can now read events on those watched files/directories even if it lacks direct read permission to them and can add and remove watches on the inotify instance, indirectly signaling the C1 process via the shared inotify instance. All of which would be avoided if the MLS policy included a constraint on fd use permission, thereby preventing such sharing of inotify instances among processes in different levels except for trusted subjects or objects identified by a type attribute. -- Stephen Smalley National Security Agency From amy.griffis at hp.com Mon Sep 11 19:34:51 2006 From: amy.griffis at hp.com (Amy Griffis) Date: Mon, 11 Sep 2006 15:34:51 -0400 Subject: [redhat-lspp] Re: inotify_rm_watch behavior In-Reply-To: <1158002159.5960.118.camel@moss-spartans.epoch.ncsc.mil> References: <200609111505.24567.efleury@br.ibm.com> <20060911184903.GA32335@fc.hp.com> <1158002159.5960.118.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20060911193450.GA2542@fc.hp.com> Stephen Smalley wrote: [Mon Sep 11 2006, 03:15:59PM EDT] > On Mon, 2006-09-11 at 14:49 -0400, Amy Griffis wrote: > > Eduardo Madeira Fleury wrote: [Mon Sep 11 2006, 02:05:24PM EDT] > > > I'm doing some tests and currently inotify_rm_watch is not performing any > > > permission checks, i.e., an ordinary user can remove a watch set by root on a > > > file with root:root 400 permission. > > > > > > Is this the expected behavior? Seems like neither MAC nor MLS checks are being > > > done. > > > > Yes. As I understand it, an inotify watch is not a data object, and > > so does not require DAC or MAC checks. > > Not sure I follow the rationale for MAC. Process in security context C1 > creates an inotify instance, adds some watches to files/directories it > can read (read permission checked between C1 and file context upon > inotify_add_watch), provides the instance descriptor to a process in > security context C2 via execve inheritance or local IPC. Process in > security context C2 can now read events on those watched > files/directories even if it lacks direct read permission to them and > can add and remove watches on the inotify instance, indirectly signaling > the C1 process via the shared inotify instance. > > All of which would be avoided if the MLS policy included a constraint on > fd use permission, thereby preventing such sharing of inotify instances > among processes in different levels except for trusted subjects or > objects identified by a type attribute. Agreed. I was trying to say that there shouldn't be a constraint on the inotify watch itself. Until I saw your mail, I wasn't aware that there aren't currently any constraints on sharing inotify instances. Amy From sds at tycho.nsa.gov Tue Sep 12 13:45:57 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 12 Sep 2006 09:45:57 -0400 Subject: [redhat-lspp] Re: inotify_rm_watch behavior In-Reply-To: <20060911193450.GA2542@fc.hp.com> References: <200609111505.24567.efleury@br.ibm.com> <20060911184903.GA32335@fc.hp.com> <1158002159.5960.118.camel@moss-spartans.epoch.ncsc.mil> <20060911193450.GA2542@fc.hp.com> Message-ID: <1158068757.324.94.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-09-11 at 15:34 -0400, Amy Griffis wrote: > Stephen Smalley wrote: [Mon Sep 11 2006, 03:15:59PM EDT] > > On Mon, 2006-09-11 at 14:49 -0400, Amy Griffis wrote: > > > Eduardo Madeira Fleury wrote: [Mon Sep 11 2006, 02:05:24PM EDT] > > > > I'm doing some tests and currently inotify_rm_watch is not performing any > > > > permission checks, i.e., an ordinary user can remove a watch set by root on a > > > > file with root:root 400 permission. > > > > > > > > Is this the expected behavior? Seems like neither MAC nor MLS checks are being > > > > done. > > > > > > Yes. As I understand it, an inotify watch is not a data object, and > > > so does not require DAC or MAC checks. > > > > Not sure I follow the rationale for MAC. Process in security context C1 > > creates an inotify instance, adds some watches to files/directories it > > can read (read permission checked between C1 and file context upon > > inotify_add_watch), provides the instance descriptor to a process in > > security context C2 via execve inheritance or local IPC. Process in > > security context C2 can now read events on those watched > > files/directories even if it lacks direct read permission to them and > > can add and remove watches on the inotify instance, indirectly signaling > > the C1 process via the shared inotify instance. > > > > All of which would be avoided if the MLS policy included a constraint on > > fd use permission, thereby preventing such sharing of inotify instances > > among processes in different levels except for trusted subjects or > > objects identified by a type attribute. > > Agreed. I was trying to say that there shouldn't be a constraint on > the inotify watch itself. Until I saw your mail, I wasn't aware that > there aren't currently any constraints on sharing inotify instances. Yes, I pointed this out during the "Syscalls questions" discussion back in June. Not sure why no one bothered adding such a constraint to MLS policy at the time. It would be something like: policy/mls: # No sharing of open file descriptions between levels unless # the process type is authorized to use fds created by # other levels (mlsfduse) or the fd type is authorized to # shared among levels (mlsfdshare). mlsconstrain fd use ( l1 eq l2 or t1 == mlsfduse or t2 == mlsfdshare); policy/modules/kernel/mls.te: attribute mlsfduse; attribute mlsfdshare; policy/modules/kernel/mls.if: interface(`mls_fd_use',` gen_require(` attribute mlsfduse; ') typeattribute $1 mlsfduse; ') interface(`mls_fd_share',` gen_require(` attribute mlsfdshare; ') typeattribute $1 mlsfdshare; ') And then one would add mls_fd_use() and mls_fd_share() as appropriate to types in the policy, e.g. policy/modules/system/selinuxtil.te: mls_fd_share(newrole_t) and likewise for login and friends. Naturally, one would need to exercise the system quite a bit to work out exactly what domains require such use/sharing. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Sep 12 14:10:21 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 12 Sep 2006 10:10:21 -0400 Subject: [redhat-lspp] Re: inotify_rm_watch behavior In-Reply-To: <1158068757.324.94.camel@moss-spartans.epoch.ncsc.mil> References: <200609111505.24567.efleury@br.ibm.com> <20060911184903.GA32335@fc.hp.com> <1158002159.5960.118.camel@moss-spartans.epoch.ncsc.mil> <20060911193450.GA2542@fc.hp.com> <1158068757.324.94.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1158070221.324.106.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-09-12 at 09:45 -0400, Stephen Smalley wrote: > Yes, I pointed this out during the "Syscalls questions" discussion back > in June. Not sure why no one bothered adding such a constraint to MLS > policy at the time. It would be something like: > policy/mls: > # No sharing of open file descriptions between levels unless > # the process type is authorized to use fds created by > # other levels (mlsfduse) or the fd type is authorized to > # shared among levels (mlsfdshare). > mlsconstrain fd use ( l1 eq l2 or t1 == mlsfduse or t2 == mlsfdshare); > > policy/modules/kernel/mls.te: > attribute mlsfduse; > attribute mlsfdshare; > > policy/modules/kernel/mls.if: > interface(`mls_fd_use',` > gen_require(` > attribute mlsfduse; > ') > > typeattribute $1 mlsfduse; > ') > > interface(`mls_fd_share',` > gen_require(` > attribute mlsfdshare; > ') > > typeattribute $1 mlsfdshare; > ') > > > And then one would add mls_fd_use() and mls_fd_share() as appropriate to > types in the policy, e.g. > policy/modules/system/selinuxtil.te: > mls_fd_share(newrole_t) > > and likewise for login and friends. > > Naturally, one would need to exercise the system quite a bit to work out > exactly what domains require such use/sharing. BTW, the closest equivalent in the TE policy is the 'privfd' attribute and the domain_interactive_fd() and domain_use_interactive_fd() interfaces. -- Stephen Smalley National Security Agency From dgoeddel at trustedcs.com Tue Sep 12 14:09:31 2006 From: dgoeddel at trustedcs.com (Darrel Goeddel) Date: Tue, 12 Sep 2006 09:09:31 -0500 Subject: [redhat-lspp] Re: inotify_rm_watch behavior In-Reply-To: <1158068757.324.94.camel@moss-spartans.epoch.ncsc.mil> References: <200609111505.24567.efleury@br.ibm.com> <20060911184903.GA32335@fc.hp.com> <1158002159.5960.118.camel@moss-spartans.epoch.ncsc.mil> <20060911193450.GA2542@fc.hp.com> <1158068757.324.94.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4506BF9B.5040808@trustedcs.com> Stephen Smalley wrote: > On Mon, 2006-09-11 at 15:34 -0400, Amy Griffis wrote: > >>Stephen Smalley wrote: [Mon Sep 11 2006, 03:15:59PM EDT] >> >>>On Mon, 2006-09-11 at 14:49 -0400, Amy Griffis wrote: >>> >>>>Eduardo Madeira Fleury wrote: [Mon Sep 11 2006, 02:05:24PM EDT] >>>> >>>>>I'm doing some tests and currently inotify_rm_watch is not performing any >>>>>permission checks, i.e., an ordinary user can remove a watch set by root on a >>>>>file with root:root 400 permission. >>>>> >>>>>Is this the expected behavior? Seems like neither MAC nor MLS checks are being >>>>>done. >>>> >>>>Yes. As I understand it, an inotify watch is not a data object, and >>>>so does not require DAC or MAC checks. >>> >>>Not sure I follow the rationale for MAC. Process in security context C1 >>>creates an inotify instance, adds some watches to files/directories it >>>can read (read permission checked between C1 and file context upon >>>inotify_add_watch), provides the instance descriptor to a process in >>>security context C2 via execve inheritance or local IPC. Process in >>>security context C2 can now read events on those watched >>>files/directories even if it lacks direct read permission to them and >>>can add and remove watches on the inotify instance, indirectly signaling >>>the C1 process via the shared inotify instance. >>> >>>All of which would be avoided if the MLS policy included a constraint on >>>fd use permission, thereby preventing such sharing of inotify instances >>>among processes in different levels except for trusted subjects or >>>objects identified by a type attribute. >> >>Agreed. I was trying to say that there shouldn't be a constraint on >>the inotify watch itself. Until I saw your mail, I wasn't aware that >>there aren't currently any constraints on sharing inotify instances. > > > Yes, I pointed this out during the "Syscalls questions" discussion back > in June. Not sure why no one bothered adding such a constraint to MLS > policy at the time. It would be something like: > policy/mls: > # No sharing of open file descriptions between levels unless > # the process type is authorized to use fds created by > # other levels (mlsfduse) or the fd type is authorized to > # shared among levels (mlsfdshare). > mlsconstrain fd use ( l1 eq l2 or t1 == mlsfduse or t2 == mlsfdshare); > > policy/modules/kernel/mls.te: > attribute mlsfduse; > attribute mlsfdshare; > > policy/modules/kernel/mls.if: > interface(`mls_fd_use',` > gen_require(` > attribute mlsfduse; > ') > > typeattribute $1 mlsfduse; > ') > > interface(`mls_fd_share',` > gen_require(` > attribute mlsfdshare; > ') > > typeattribute $1 mlsfdshare; > ') > > > And then one would add mls_fd_use() and mls_fd_share() as appropriate to > types in the policy, e.g. > policy/modules/system/selinuxtil.te: > mls_fd_share(newrole_t) > > and likewise for login and friends. > > Naturally, one would need to exercise the system quite a bit to work out > exactly what domains require such use/sharing. The approach outlined above looks good. -- Darrel From thompsmc at us.ibm.com Tue Sep 12 15:23:21 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Tue, 12 Sep 2006 10:23:21 -0500 Subject: [redhat-lspp] LSPP Development Telecon 09/11/2006 Message-ID: <4506D0E9.3020900@us.ibm.com> 08/21/2006 lspp Meeting Minutes: =============================== Attendees Robin Redden (IBM) - RR George Wilson (IBM) - GW Michael Thompson (IBM) - MT Thiago Bauermann (IBM) - TB Al Viro (Red Hat) - AV Irina Boverman (Red Hat) - IB Lisa Smith (HP) - LMS Amy Griffis (HP) - AG Matt Anderson (HP) - MA Joe Nall - JN Bill O'Donnel (SGI) - BO Dan Walsh (Red Hat) - DW Debora Velarde (IBM) - DV Lenny Bruzanak - LB Ted Toth - TT Linda Knippers (HP) - LK Forgive me if any names are mis-spelled or statements attributed to the wrong voice. :) Tentative Agenda: Kernel / Rawhide update SELinux base update MLS policy issues Audit userspace Print CIPSO IPsec xinetd ipsec-tools: SPD dump and racoon base + MLS Single-user mode Self tests VFS polyinstantiation Cron, tmpwatch, mail, etc. Bugs / remaining tasks Final cutoff date Announcements ------------- GW: Janak Desai has left the project. He has taken a new opportunity within IBM. There should be some backfill. Farewell Janak :) Kernel / Rawhide update ----------------------- AV: Steve Grubb and Al's stuff got into mainline (should take care of some line items). Rawhide should see these changes in a few days, mainline has, and MM will get once Andrew rebases. GW: Can we mix beta and rawhide? SG: Yes, for a while, no major changes so in some cases you should be able to interchange. GW: Seen a problem on fc5+rawhide where root can't change his or other's passwords. Haven't tested on beta yet. DV: Seen this on alpha with rawhide layered GW: We need to retry this on the beta AV: For syscall classes, andrew added support for ppc/ppc64/s390x. Probably want to carefully test these. This doesn't differ much on amd64 and the like since they already have the change. GW: yes, we need to retest carefully DW: Changing passwords works ok for me on beta GW: ok, that's probably an alpha bug SG: Bugzilla re: ppc shared memory values problem, don't have access to a ppc machine to do any real debug work. GW: Try to work with IBM kernel developers? MT: ok SG: Confirmed that ppid seems to be backwards (= != flipped) and needs to be looked into AV: Interesting... GW: Is that code dustin wrote? LK: Are there bugzillas for this stuff that we can see? GW: Yes, but it's usually painful. We have to add to a confidential group which makes difficult for others to find/see them. Can we change this with RH's bugzilla? IB: We can change that... maybe not GW: RHIT bugs are now opaque to us SG: We've talked about these bugs on IRC, and we need to start looking into them. These are only bugs that we're tracking with the audit system. AV: I'm looking at ppc code right now... don't see any difference MT: Seen this on both ppc and x86_64 AV: Audit pid works correctly SG: MT: AV: what the heck... SG: for ppc shared mem, can't really work on, no hardware GW: we need to leverage our internal hands IPsec ----- JN: Confused about IPsec, it seems IPsec not doing what people think it should intuitively. What are the plans for all the reconsilliation patches? Is IPsec going to be usefl from an application developer prospective? GW: I thought the upshot of that email thread was joy and venkat finding a bug LK: I would appriciated a big picture of whats going on GW: I think its bug fixes, Joy could tell us more LK: I think Venkat took patches to the list... don't know whats missing if these patches don't make it, etc JN: I think he reposted those patches, am putting a system together to run Joshua Brendal's test GW: I need to get in touch with Venkat and Joy GW: Joy to produce write up (not seen yet) to clarify setup and produce some example policy. Joy claims testing in enforcing mode and complete label flow. Suspects Joshua had setup problems or found a bug... thinks might be a bug. LK: This all might be unrelated to Venkat's patches GW: Yes, she wouldn't e testing with those patches, she was just testing with IPsec stress and she found memmv memcpy bugs on ppc Hoping that she can do write up now that she's done. Will get in touch with Venkat and Joy to follow up. JN: Any intent to update racoon to negotiate the labels for automation? GW: Venkat has given joy this patch, but Joy hit the oops so she couldn't continue testing. JN: That's this patch? GW: Yes, I think that's one of the patches Venkat produced. Need to get a handle on Joy and Venkat's status about this. Think Joy was supposed to send on Venkat's pathes for integrated patches to netdev SELinux base update ------------------- DW: 2 things, 1 been mucking around trying to get rpm and yum working right. Right now, when we run rpm, when it runs post install its also running at sysadm_r, which is not sufficient. i.e. yum update will get scriplet failures trying to get sysadm_r to automatically transition to system_r, but its difficult to do this due to run_init. DW: Thinking we should make users run "rpm" under run_init, but this is going to be a usability nightmare (reauthentication) MA: Isn't run_init like newrole? can't we have a "root OK" style confirm? DW: Not sure MA: Getting password prompt to authenticate on newrole to sysadm_r DW: This might work. Going to restrict rpm to run_init only, to allow for easy transitions DW: Issue 2 is cron is running as user_cron_t, which means its filling up sys logs with AVC messages. cron patch probably not right, since its running scripts with the wrong context. DW: Infamous boot to single mode on failure, will go to single user. We have a patch in place. Using a flag that we're not cleaning up. SG: Few things for SELinux: secmark looks like later this week initial patches will be going into iptabels, but won't be the complete patch. People can start experimenting. SG: Are we going to start testing the scripts and stuff from policycoreutils? GW: We're focusing on certification testing SG: What kind of testing coverage is going to be given to SELinux? Like setenforce and sestatus? GW: Security relevant will be more throughly tested than informational SG: But like restorecon etc GW: yes, those will be heavily test, like semanage, etc all the important ones. They will receive fairly extensive testing needs to be done to meet CC testing requirements SG: Linda, what about you guys? are you looking into policycoreutils and libselinux? LK: My answer is like George's GW: We don't want to ship broken code, but we can't afford to spend that bandwidth. We want to get as much FVT as we can, but we can't do it all SG: Wondering if other packages will get the same attention as audit GW: Philosophy has to be low-level testing, not necessarily at the higher levels SG: I would like to see restorecon tested heavily LK: You'll see test caeses written around tools listed in the config guide LK: We could use instructions on how to take RHEL5 beta and how to get it into enforcing mode correctly GW: We're using rawhide packages on top of the beta LK: Not seeing any issues? GW: I don't think so, but that password problem might be related. As Steve said, if thinks haven't moved too far, should be OK. LK: If we find a problem in the beta with rawhide packages, who do we label it against? SG: If you file against rawhide, we'll fix rawhide but we need to remember to port to beta LK: Didn't see an MLS policy in the beta GW: Key thing is to CC Irina, Dan and Steve GW: Question, will there be an update repo from the beta or do we keep pulling from rawhide? IB: I think we're planning a repo which would be refreshed once a week GW: Good, we need that package confidence IB: Bugs against rawhide usually need to be opened twice, I'll try to keep track of these DW: Open these against RHEL5, esp. if in the policy tool chain Audit userspace --------------- SG: No news GW: Should we drop this from the agenda? SG: I'll have stuff going in, mostly normal bugs and audit parse library GW: Will leave a generic audit related item in the agenda Print ----- GW: Matt, how is print going? MA: Not too bad, have had feedback regarding audit messages, working on this suggestion was a user banner, final banner override field in messages lprm only doing DAC check, and cancel is going on the same code path need to get an new version out that has MLS check. MA: Posted re: what just works means for MCS. think MCS if no category, then leave label off, assume sysadm didn't want a label applied because user operating without categories thats about it GW: Hope you get feedback from the post CIPSO ----- LK: Paul on travel, no news on CIPSO JN: Wrote a pretty complicated policy that seems to be working. Send me (Joe Nall) an email if you want a copy of this. LK: Glad to see tools made it into extras JN: What happens right now if you turn netlabel on, your not able to access the net because those packets are unlabeled xinetd ------ TT: Have extended internally to use. So far so good SG: xinetd has ability to relay between networks, will disable in favor of iptables TT: Should xinetd use pam_namespaces to get things to the right namespace? Am concerned with multi-level stuff. SG: No, xinetd tries to stay out of pam, but not hard to write a program that creates the "pam-ified" environment. TT: So that's what we should do? SG: Yeah, a program called "pam tester", available at freshmeat, which launches a bunch of utils TT: We have a bunch of internal apps which launch though xinetd, and most of them rely on polyinstantiated /tmp and trying to figure out how to best recreate that, will look at pam_test and let you know what I find. Selftest -------- SG: Disable prelink GW: Recommended ripping out and using 8? SG: Possibly, if it does show up in beta2, do that, but don't do that work yet. SG: James will hook it up with the audit system so if we find a mismatch then we can send messages to audit. GW: One of the problems I found was RPM misclassifying things, like config files not being noted as such SG: Not every config file is labeled that way, because its a note to RPM to not overwrite this file GW: Would be nice if I had a real integrety checker to call into SG: That's the hope VFS polyinstantiation & cron ---------------------------- GW: Janak will try to help out here, but his time is re-allocated. We'll try to pick up the slack, but we're - 1(janak). Bugs / remaining tasks ---------------------- GW: Keep testing and filing bugs, need to test integration, esp in networking. Need focus on IPsec rather desperately need to flush out how things should be set up and how to write tests, and we need the integration test. GW: For communication on the bugs, if they are not confidential, should we posting the bug abstract to the list? LK: Yes, that would be nice. Paul has done this before. GW: If we could share abstracts, it would be beneficial if Red Hat is OK with this? IB: Yes, should be ok LK: I think I've seen bugs where IBM, RH, HP and Klaus are all working together IB: I can set a bug to be IBM and HP confidential, so I can do that and it can be seen by both GW: If we don't check confidential boxes, it should be public yes? IB: Yes, that's what I thought IB: I will see if its OK to post the list of bugs to the LSPP list GW: Yes, that's the preferable approach rather than us deciding confidential or not Final cutoff date ----------------- GW: What is the final cut-off date? IB: I don't think we know, think Oct 4th is the 2nd beta date, but that's not finalized IB: I would encourage people to do as much as they can in the next 2-3 weeks ~Fin From thompsmc at us.ibm.com Tue Sep 12 15:53:57 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Tue, 12 Sep 2006 10:53:57 -0500 Subject: [redhat-lspp] LSPP Development Telecon 09/11/2006 In-Reply-To: <4506D0E9.3020900@us.ibm.com> References: <4506D0E9.3020900@us.ibm.com> Message-ID: <4506D815.8040407@us.ibm.com> And yes, Steve Grubb (Red Hat) - SG was there... Sorry Steve! From latten at austin.ibm.com Wed Sep 13 00:01:50 2006 From: latten at austin.ibm.com (Joy Latten) Date: Tue, 12 Sep 2006 19:01:50 -0500 Subject: [redhat-lspp] racoon patch with Venkat's changes Message-ID: <200609130001.k8D01o7r018391@faith.austin.ibm.com> This patch is to include Venkat's changes to racoon for negotiating the security context with MLS. This patch is against the ipsec-tools-0.6.5-3.1 rpm in rawhide. I have not yet had a chance to test it, so if you have problems, please let me know. Regards, Joy Latten diff -urpN ipsec-tools-0.6.5.orig/src/racoon/isakmp_quick.c ipsec-tools-0.6.5.patch/src/racoon/isakmp_quick.c --- ipsec-tools-0.6.5.orig/src/racoon/isakmp_quick.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.patch/src/racoon/isakmp_quick.c 2006-08-22 02:22:57.000000000 -0500 @@ -2128,5 +2128,11 @@ get_proposal_r(iph2) return ISAKMP_INTERNAL_ERROR; } +#ifdef HAVE_SECCTX + if (spidx.sec_ctx.ctx_str) { + set_secctx_in_proposal(iph2, spidx); + } +#endif /* HAVE_SECCTX */ + return 0; } diff -urpN ipsec-tools-0.6.5.orig/src/racoon/pfkey.c ipsec-tools-0.6.5.patch/src/racoon/pfkey.c --- ipsec-tools-0.6.5.orig/src/racoon/pfkey.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.patch/src/racoon/pfkey.c 2006-08-22 02:27:21.000000000 -0500 @@ -1672,6 +1672,9 @@ pk_recvacquire(mhp) struct ph2handle *iph2[MAXNESTEDSA]; struct sockaddr *src, *dst; int n; /* # of phase 2 handler */ +#ifdef HAVE_SECCTX + struct sadb_x_sec_ctx *m_sec_ctx; +#endif /* HAVE_SECCTX */ /* ignore this message because of local test mode. */ if (f_local) @@ -1691,6 +1694,24 @@ pk_recvacquire(mhp) src = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_SRC]); dst = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_DST]); +#ifdef HAVE_SECCTX + m_sec_ctx = (struct sadb_x_sec_ctx *)mhp[SADB_X_EXT_SEC_CTX]; + + if (m_sec_ctx != NULL) { + plog(LLV_INFO, LOCATION, NULL, + "security context doi: %u\n", + m_sec_ctx->sadb_x_ctx_doi); + plog(LLV_INFO, LOCATION, NULL, + "security context algorithm: %u\n", + m_sec_ctx->sadb_x_ctx_alg); + plog(LLV_INFO, LOCATION, NULL, + "security context length: %u\n", + m_sec_ctx->sadb_x_ctx_len); + plog(LLV_INFO, LOCATION, NULL, "security context: %s\n", + ((char *)m_sec_ctx + sizeof(struct sadb_x_sec_ctx))); + } +#endif /* HAVE_SECCTX */ + /* ignore if type is not IPSEC_POLICY_IPSEC */ if (xpl->sadb_x_policy_type != IPSEC_POLICY_IPSEC) { plog(LLV_DEBUG, LOCATION, NULL, @@ -1786,10 +1807,16 @@ pk_recvacquire(mhp) spidx.prefs = sp_out->spidx.prefd; spidx.prefd = sp_out->spidx.prefs; spidx.ul_proto = sp_out->spidx.ul_proto; + #ifdef HAVE_SECCTX - if (*sp_out->spidx.sec_ctx.ctx_str) - memcpy(&spidx.sec_ctx, &sp_out->spidx.sec_ctx, - sizeof(spidx.sec_ctx)); + if (m_sec_ctx) { + spidx.sec_ctx.ctx_doi = m_sec_ctx->sadb_x_ctx_doi; + spidx.sec_ctx.ctx_alg = m_sec_ctx->sadb_x_ctx_alg; + spidx.sec_ctx.ctx_strlen = m_sec_ctx->sadb_x_ctx_len; + memcpy(spidx.sec_ctx.ctx_str, + ((char *)m_sec_ctx + sizeof(struct sadb_x_sec_ctx)), + spidx.sec_ctx.ctx_strlen); + } #endif sp_in = getsp(&spidx); @@ -1877,6 +1904,12 @@ pk_recvacquire(mhp) delph2(iph2[n]); return -1; } +#ifdef HAVE_SECCTX + if (m_sec_ctx) { + set_secctx_in_proposal(iph2[n], spidx); + } +#endif /* HAVE_SECCTX */ + insph2(iph2[n]); /* start isakmp initiation by using ident exchange */ diff -urpN ipsec-tools-0.6.5.orig/src/racoon/policy.c ipsec-tools-0.6.5.patch/src/racoon/policy.c --- ipsec-tools-0.6.5.orig/src/racoon/policy.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.patch/src/racoon/policy.c 2006-08-22 02:32:10.000000000 -0500 @@ -206,9 +206,13 @@ cmpspidxstrict(a, b) #ifdef HAVE_SECCTX if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi +#if 1 + || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) +#else || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, a->sec_ctx.ctx_strlen) != 0)) +#endif return 1; #endif return 0; @@ -284,9 +288,13 @@ cmpspidxwild(a, b) #ifdef HAVE_SECCTX if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi +#if 1 + || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) +#else || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, a->sec_ctx.ctx_strlen) != 0)) +#endif return 1; #endif diff -urpN ipsec-tools-0.6.5.orig/src/racoon/policy.h ipsec-tools-0.6.5.patch/src/racoon/policy.h --- ipsec-tools-0.6.5.orig/src/racoon/policy.h 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.patch/src/racoon/policy.h 2006-08-22 02:20:28.000000000 -0500 @@ -35,6 +35,8 @@ #include #ifdef HAVE_SECCTX +#include + #define MAX_CTXSTR_SIZE 50 struct security_ctx { u_int8_t ctx_doi; /* Security Context DOI */ @@ -146,6 +148,10 @@ extern void initsp __P((void)); extern struct ipsecrequest *newipsecreq __P((void)); extern const char *spidx2str __P((const struct policyindex *)); +#ifdef HAVE_SECCTX extern int get_security_context __P((vchar_t *, struct policyindex *)); +extern int within_range __P((security_context_t, security_context_t)); +extern void set_secctx_in_proposal __P((struct *ph2handle, struct policyindex)); +#endif #endif /* _POLICY_H */ diff -urpN ipsec-tools-0.6.5.orig/src/racoon/proposal.c ipsec-tools-0.6.5.patch/src/racoon/proposal.c --- ipsec-tools-0.6.5.orig/src/racoon/proposal.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.patch/src/racoon/proposal.c 2006-08-22 02:34:25.000000000 -0500 @@ -1025,15 +1025,6 @@ set_proposal_from_policy(iph2, sp_main, newpp->lifetime = iph2->sainfo->lifetime; newpp->lifebyte = iph2->sainfo->lifebyte; newpp->pfs_group = iph2->sainfo->pfs_group; -#ifdef HAVE_SECCTX - if (*sp_main->spidx.sec_ctx.ctx_str) { - newpp->sctx.ctx_doi = sp_main->spidx.sec_ctx.ctx_doi; - newpp->sctx.ctx_alg = sp_main->spidx.sec_ctx.ctx_alg; - newpp->sctx.ctx_strlen = sp_main->spidx.sec_ctx.ctx_strlen; - memcpy(newpp->sctx.ctx_str, sp_main->spidx.sec_ctx.ctx_str, - sp_main->spidx.sec_ctx.ctx_strlen); - } -#endif /* HAVE_SECCTX */ if (lcconf->complex_bundle) goto skip1; @@ -1196,7 +1187,11 @@ set_proposal_from_proposal(iph2) pp0->sctx.ctx_strlen = pp_peer->sctx.ctx_strlen; memcpy(pp0->sctx.ctx_str, pp_peer->sctx.ctx_str, pp_peer->sctx.ctx_strlen); + + plog(LLV_INFO, LOCATION, NULL, + "RESPONDING with (%s).\n", pp_peer->sctx.ctx_str); } + #endif /* HAVE_SECCTX */ if (pp_peer->next != NULL) { diff -urpN ipsec-tools-0.6.5.orig/src/racoon/security.c ipsec-tools-0.6.5.patch/src/racoon/security.c --- ipsec-tools-0.6.5.orig/src/racoon/security.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.patch/src/racoon/security.c 2006-08-22 02:46:01.000000000 -0500 @@ -1,5 +1,6 @@ /* * Copyright (C) 2005 International Business Machines Corporation + * Copyright (c) 2005 by Trusted Computer Solutions, Inc. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -36,6 +37,12 @@ #include #include +#include +#include +#include +#include +#include + #include "var.h" #include "vmbuf.h" #include "misc.h" @@ -150,3 +157,109 @@ get_security_context(sa, p) } return 0; } + +void +set_secctx_in_proposal(iph2, spidx) + struct ph2handle *iph2; + struct policyindex spidx; +{ + iph2->proposal->sctx.ctx_doi = spidx.sec_ctx.ctx_doi; + iph2->proposal->sctx.ctx_alg = spidx.sec_ctx.ctx_alg; + iph2->proposal->sctx.ctx_strlen = spidx.sec_ctx.ctx_strlen; + memcpy(iph2->proposal->sctx.ctx_str, spidx.sec_ctx.ctx_str, + spidx.sec_ctx.ctx_strlen); +} + + +/* + * function: init_avc + * description: function performs the steps necessary to initialize the + * userspace avc. + * input: void + * return: 0 if avc was successfully initialized + * 1 if the avc could not be initialized + */ + +static int +init_avc(void) +{ + int rtn = 0; + + if (!is_selinux_mls_enabled()) { + plog(LLV_ERROR, LOCATION, NULL, "racoon: MLS support is not" + " enabled.\n"); + return 1; + } + + rtn = avc_init("racoon", NULL, NULL, NULL, NULL); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, "racoon: could not initialize avc.\n"); + rtn = 1; + } + return rtn; +} + +/* + * function: within_range + * description: function determines if the specified sl is within the + * configured range for a policy rule. + * input: security_context *sl SL + * char *range Range + * return: 1 if the sl is within the range + * 0 if the sl is not within the range or an error + * occurred which prevented the determination + */ + +int +within_range(security_context_t sl, security_context_t range) +{ + int rtn = 1; + security_id_t slsid; + security_id_t rangesid; + struct av_decision avd; + security_class_t tclass; + access_vector_t av; + + rtn = init_avc(); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: couldn't initialize the AVC\n"); + return 0; + } + + /* + * Get the sids for the sl and range contexts + */ + rtn = avc_context_to_sid(sl, &slsid); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: Unable to retrieve " + "sid for sl context (%s).\n", sl); + return 0; + } + rtn = avc_context_to_sid(range, &rangesid); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: Unable to retrieve " + "sid for range context (%s).\n", range); + sidput(slsid); + return 0; + } + + /* + * Straight up test between sl and range + */ + tclass = SECCLASS_ASSOCIATION; + av = ASSOCIATION__POLMATCH; + rtn = avc_has_perm(slsid, rangesid, tclass, av, NULL, &avd); + if (rtn != 0) { + plog(LLV_INFO, LOCATION, NULL, + "within_range: The sl is not within range\n"); + sidput(slsid); + sidput(rangesid); + return 0; + } + plog(LLV_DEBUG, LOCATION, NULL, + "within_range: The sl (%s) is within range (%s)\n", sl, range); + return 1; +} From latten at austin.ibm.com Wed Sep 13 00:57:40 2006 From: latten at austin.ibm.com (Joy Latten) Date: Tue, 12 Sep 2006 19:57:40 -0500 Subject: [redhat-lspp] racoon patch is incorrect... Message-ID: <200609130057.k8D0veuB018660@faith.austin.ibm.com> Hello, I sent out the incorrect racoon patch. The one sent has compile errors. I will send out the correct patch shortly. Regards, Joy From sds at tycho.nsa.gov Wed Sep 13 20:19:15 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 13 Sep 2006 16:19:15 -0400 Subject: [redhat-lspp] Re: Polyinstantiation based on context with MLS In-Reply-To: References: Message-ID: <1158178755.15278.186.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-09-13 at 14:16 -0400, Rosalie Hiebel wrote: > We're trying to understand the policy rules in relation to how > instance directories of polyinstantiated directories get created when > polyinstantiation is done by context. > > My goal is to have a different instance directory created/mounted for > each different context in which an application is running when it > accesses this directory. For example, if running in a context with > MLS level s1-s1, I would expect to see a different instance than when > running in that same context but whose MLS level is s2-s2. > > The problem is that I cannot get a different instance set up in these > 2 cases; whether running at s1 or s2, the instance directory has a > context with an MLS level of SystemLow-SystemHigh. This is the MLS > range I had set up for the polyinstantiated dir (/var/poly) and the > directory which contains the instances (/var/poly/poly-inst). > > I added an entry to /etc/security/namespace.conf which contained "context" > /var/poly /var/poly/poly-inst context root,adm > > My understanding was that the actual instance directory creation and > mounting for a process was done through the pam_namespace module. > Also, if my application called these pam session routines to set up > instance directories, it would have to first call setexeccon prior to > setting up a pam session. (Otherwise, pam would override the > "context" setting in namespace.conf and create/mount an instance > based on user instead of context.) > > To have instance directories actually created by context, I had my > test program obtain its current context, set the mls level in this > context to either "s1-s1" or "s2-s2", and then pass this context to > both setcon and setexeccon. It then calls the pam routines > pam_start() and pam_open_session(). (I had set up a dummy "test" > service in /etc/pam.d, and I passed this service name to pam_start > along with a "conversation" routine which simply returned > PAM_SUCCESS.) > > When I ran my test program, I looked at /var/log/secure, and > pam_namespace indicated it had successfully set up and mounted the > instance directory. > > It appears that pam_namespace calls security_compute_member to obtain > the context which it sets the newly created instance directory to > after creating it. Does the policy decide this based on the > "type_member" rules ? If this is the case, then this rule seems to > state only what the type is, and the remaining part of the context > seems to always be the context of my /var/poly directory. If this is > true, then how can it ever achieve having a different instance based > on any component of the context (such as the MLS level) being > different ? If there is a matching type_member rule (with a type that differs from the base dir), then it should return a context with the new type and the low level from the source context (which in this case would be the exec context previously set). As a side bar, it looks like there is an error in the build of the -mls policy that is leaving the usual polyinstantiation-related rules disabled (controlled by the POLY= build option). If possible, you should consider decomposing your application and running separate instances for the different levels to improve separation and reduce the trust required in the application itself. -- Stephen Smalley National Security Agency From thompsmc at us.ibm.com Thu Sep 14 14:55:28 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Thu, 14 Sep 2006 09:55:28 -0500 Subject: [redhat-lspp] MAC_POLICY_LOAD on unloading module Message-ID: <45096D60.5010902@us.ibm.com> Hey Steve, on semodule -r module, the audit message you get (MAC_POLICY_LOAD) has the exact same message as the audit message you get on semodule -i module. That is, "policy loaded". Shouldn't there be a different between module load and module unload? Mike From sds at tycho.nsa.gov Thu Sep 14 15:08:44 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 14 Sep 2006 11:08:44 -0400 Subject: [redhat-lspp] Re: MAC_POLICY_LOAD on unloading module In-Reply-To: <45096D60.5010902@us.ibm.com> References: <45096D60.5010902@us.ibm.com> Message-ID: <1158246524.25629.71.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-09-14 at 09:55 -0500, Michael C Thompson wrote: > Hey Steve, > > on semodule -r module, the audit message you get (MAC_POLICY_LOAD) has > the exact same message as the audit message you get on semodule -i > module. That is, "policy loaded". Shouldn't there be a different between > module load and module unload? >From the kernel's POV, they are both a policy load. The modular insertion/removal is done in userspace and a new kernel policy is generated and then loaded. So if you want that granularity of audit, you need it to be done in semodule or better in libsemanage (and ultimately in the policy management server when that is deployed). -- Stephen Smalley National Security Agency From joe at nall.com Thu Sep 14 18:54:12 2006 From: joe at nall.com (Joe Nall) Date: Thu, 14 Sep 2006 13:54:12 -0500 Subject: [redhat-lspp] Re: Polyinstantiation based on context with MLS In-Reply-To: <1158178755.15278.186.camel@moss-spartans.epoch.ncsc.mil> References: <1158178755.15278.186.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <76A138F7-7C39-423B-B6D8-6D6E5EA03CEA@nall.com> On Sep 13, 2006, at 3:19 PM, Stephen Smalley wrote: > > As a side bar, it looks like there is an error in the build of the - > mls > policy that is leaving the usual polyinstantiation-related rules > disabled (controlled by the POLY= build option). I think this spec file change will fix the error --- selinux-policy.spec.orig 2006-09-14 08:46:07.000000000 -0500 +++ selinux-policy.spec 2006-09-14 08:46:59.000000000 -0500 @@ -73,8 +73,8 @@ SELinux Policy development package %dir %{_usr}/share/selinux/mls %define setupCmds() \ -make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} POLY=%3 bare \ -make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} POLY=%3 conf \ +make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} POLY=%4 bare \ +make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} POLY=%4 conf \ cp -f ${RPM_SOURCE_DIR}/modules-%1.conf ./policy/modules.conf \ cp -f ${RPM_SOURCE_DIR}/booleans-%1.conf ./policy/booleans.conf \ @@ -82,18 +82,18 @@ cp -f ${RPM_SOURCE_DIR}/booleans-%1.conf awk '$1 !~ "/^#/" && $2 == "=" && $3 == "module" { printf "-i %%s.pp ", $1 }' %{_sourcedir}/modules-%{1}.conf ) %define installCmds() \ -make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} POLY=%3 base.pp \ -make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} POLY=%3 modules \ -make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} DESTDIR=%{buildroot} POLY=%3 install \ -make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} DESTDIR=%{buildroot} POLY=%3 install-appconfig \ +make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} POLY=%4 base.pp \ +make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} POLY=%4 modules \ +make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} DESTDIR=%{buildroot} POLY=%4 install \ +make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} DESTDIR=%{buildroot} POLY=%4 install-appconfig \ #%{__cp} *.pp %{buildroot}/%{_usr}/share/selinux/%1/ \ %{__mkdir} -p %{buildroot}/%{_sysconfdir}/selinux/%1/policy \ %{__mkdir} -p %{buildroot}/%{_sysconfdir}/selinux/%1/modules/active \ %{__mkdir} -p %{buildroot}/%{_sysconfdir}/selinux/%1/contexts/files \ touch %{buildroot}/%{_sysconfdir}/selinux/%1/modules/ semanage.read.LOCK \ touch %{buildroot}/%{_sysconfdir}/selinux/%1/modules/ semanage.trans.LOCK \ -make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} POLY=%3 enableaudit \ -make -W base.conf NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=%{monolithic} POLY=%3 base.pp \ +make NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=% {monolithic} POLY=%4 enableaudit \ +make -W base.conf NAME=%1 TYPE=%2 DISTRO=%{distro} DIRECT_INITRC=%3 MONOLITHIC=%{monolithic} POLY=%4 base.pp \ install -m0644 base.pp %{buildroot}%{_usr}/share/selinux/%1/ enableaudit.pp \ rm -rf %{buildroot}%{_sysconfdir}/selinux/%1/booleans \ touch %{buildroot}%{_sysconfdir}/selinux/%1/seusers \ @@ -179,7 +179,7 @@ mkdir -p %{buildroot}%{_usr}/share/selin # Install devel make clean -make NAME=targeted TYPE=targeted-mcs DISTRO=%{distro} DIRECT_INITRC=y MONOLITHIC=%{monolithic} DESTDIR=%{buildroot} PKGNAME= %{name}-%{version} POLY=%3 install-headers install-docs +make NAME=targeted TYPE=targeted-mcs DISTRO=%{distro} DIRECT_INITRC=y MONOLITHIC=%{monolithic} DESTDIR=%{buildroot} PKGNAME= %{name}-%{version} POLY=n install-headers install-docs mkdir %{buildroot}%{_usr}/share/selinux/devel/ mv %{buildroot}%{_usr}/share/selinux/targeted/include %{buildroot}% {_usr}/share/selinux/devel/include install -m 755 ${RPM_SOURCE_DIR}/policygentool %{buildroot}%{_usr}/ share/selinux/devel/ From thompsmc at us.ibm.com Thu Sep 14 20:44:12 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Thu, 14 Sep 2006 15:44:12 -0500 Subject: [redhat-lspp] Newrole failure yeilds no audit record Message-ID: <4509BF1C.7070603@us.ibm.com> Hey all, I'm seeing no audit record get produced if a newrole attempt fails due to an invalid context... is this known and expected? Mike From vivijim at br.ibm.com Thu Sep 14 22:19:44 2006 From: vivijim at br.ibm.com (Rodrigo Vivi) Date: Thu, 14 Sep 2006 19:19:44 -0300 Subject: [redhat-lspp] cups - changing printer level Message-ID: <200609141919.44806.vivijim@br.ibm.com> Hi all, How can I change the level of a printer in run time execution ? I've noticed that neither secadm has the permission to change directly the level of device using chcon. Does the policy allow changes from SystemLow to any other level for printer_device_t objects ? Thanks, Vivi. From klaus at atsec.com Thu Sep 14 22:56:52 2006 From: klaus at atsec.com (Klaus Weidner) Date: Thu, 14 Sep 2006 17:56:52 -0500 Subject: [redhat-lspp] Newrole failure yeilds no audit record In-Reply-To: <4509BF1C.7070603@us.ibm.com> References: <4509BF1C.7070603@us.ibm.com> Message-ID: <20060914225652.GA15094@w-m-p.com> On Thu, Sep 14, 2006 at 03:44:12PM -0500, Michael C Thompson wrote: > I'm seeing no audit record get produced if a newrole attempt fails due > to an invalid context... is this known and expected? I guess you could argue that an invalid attempt to use newrole doesn't count as "unsuccessful" as far as the protection profile audit requirements are concerned, similar to how you don't need an audit record if you call a trusted program with unsupported command line flags. The cleaner solution would be to have an audit record. -Klaus From sds at tycho.nsa.gov Fri Sep 15 17:40:58 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 15 Sep 2006 13:40:58 -0400 Subject: [redhat-lspp] Re: Question on type_member rule In-Reply-To: References: Message-ID: <1158342058.18951.85.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-09-15 at 08:51 -0400, Rosalie Hiebel wrote: > I'm trying to understand precisely how a type_member rule specifies > the context to place on an instance of a polyinstantiated directory > when it's done by context. > > type_member :dir ; > > What exactly will be the context placed on the instance of the > directory created by a process? Will this context be the same as > the context passed to setexeccon ? Is the placed in > the context of the instance directory ? Does running in permissive > mode result in a different context ? > > I have experimented with this, and I seem to always get instance > directories created with the same context as that of the base > directory (the one being polyinstantiated.) Let's distinguish between what security_compute_member() computes, and how pam_namespace calls and uses it. Further, before we delve too deep here, I have to ask: Does your application truly require polyinstantiated directories? From what you've described thus far, it sounds as though the application is already security-aware and multi-level, so what does it gain from polyinstantiation vs. explicit directory/file management? Polyinstantiation is more oriented toward providing compatibility for security-unaware applications when accessing a shared resource like /tmp that must be partitioned in a multi-level environment without having to modify those applications to know about per-level instances. But if the application already knows that it is operating in a multi-level environment and even knows what level it needs to operate in, why does it need polyinstantiation vs. just accessing the right subdir directly? (I'd also be interested in exploring the architecture of your application and whether it can be decomposed to minimize trust, but that is another topic.) Going back now to your questions, security_compute_member() is a function to compute a member/instance context for a given polyinstantiated object based on three inputs: 1) a source context, typically the context of the process that will be accessing the instance, 2) a target context, typically the context of the polyinstantiated object, and 3) the class of the object, so that we can distinguish different kinds of polyinstantiated objects that might ultimately exist beyond just directories. The function itself has no knowledge of how these inputs are determined; they are provided by the caller (pam_namespace in this case). The function computes a member context from these inputs based on its internal rules, which are: 1) Look for a type_member rule that matches the type from the source context (source_type), the type from the target context (target_type), and the class. 2) If no such rule exists, then the function just returns a member context equal to the target context (no instantiation). 3) If a rule exists, then use the member_type from the rule as the type in the member context. Further, if that member_type differs from the target_type (*), use the level of the source context as the level in the member context. (*) Implementation artifact: In concept, the type_member rule indicates when to polyinstantiate an object, and it was assumed that one would always want to polyinstantiate by type as well as level in such cases, so member_type != target_type is used as the test in the MLS component to determine whether it should polyinstantiate levels. That could be changed (in fact, there was some discussion of it in the past), but until such a change occurs, you need to use member_type != target_type in the rule to cause instantiation to occur. pam_namespace uses security_compute_member() to get the member context. It passes the following as inputs: 1) the exec context as the source context, 2) the context of the directory to be polyinstantiated as the target context. 3) the directory class. The use of the exec context is because we want to instantiate based on the context of the process that will be accessing the member, which is typically _not_ the current process. Instead, it is typically a user shell or other program executed by the current process (or a child) that will run in the exec context rather than the current one. This is the case for e.g. login and newrole. If your application doesn't follow such a model, we need to talk about your application's architecture. Examples of type_member rules from the refpolicy: type_member user_t tmp_t:dir user_tmp_t; type_member staff_t tmp_t:dir staff_tmp_t; Then, if pam_namespace is configured to polyinstantiate /tmp by context and the user is not in the list of excluded uids, it would call security_compute_member with the exec context (set by the caller of pam_namespace, e.g. sds:staff_r:staff_t:s3) and the context of the /tmp directory (e.g. system_u:object_r:tmp_t:s0). security_compute_member() would find the matching type_member rule for (staff_t, tmp_t) and should return the context system_u:object_r:staff_tmp_t:s3 as the member/instance context. -- Stephen Smalley National Security Agency From sgrubb at redhat.com Fri Sep 15 19:16:08 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 15 Sep 2006 15:16:08 -0400 Subject: [redhat-lspp] Newrole failure yeilds no audit record In-Reply-To: <20060914225652.GA15094@w-m-p.com> References: <4509BF1C.7070603@us.ibm.com> <20060914225652.GA15094@w-m-p.com> Message-ID: <200609151516.08100.sgrubb@redhat.com> On Thursday 14 September 2006 18:56, Klaus Weidner wrote: > The cleaner solution would be to have an audit record. OK, we'll make some patches to fix this. What other SE Linux programs are considered "trusted" and require audit messages when they fail to be used properly? The only other program that I can think of that is audit enhanced is semanage. -Steve From sds at tycho.nsa.gov Fri Sep 15 19:28:25 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 15 Sep 2006 15:28:25 -0400 Subject: [redhat-lspp] Newrole failure yeilds no audit record In-Reply-To: <200609151516.08100.sgrubb@redhat.com> References: <4509BF1C.7070603@us.ibm.com> <20060914225652.GA15094@w-m-p.com> <200609151516.08100.sgrubb@redhat.com> Message-ID: <1158348505.18951.130.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-09-15 at 15:16 -0400, Steve Grubb wrote: > On Thursday 14 September 2006 18:56, Klaus Weidner wrote: > > The cleaner solution would be to have an audit record. > > OK, we'll make some patches to fix this. Are you sure? What do you want to audit? newrole -r typoinrolename ? newrole -r sysadm_r for user not authorized for that role? any error exit path out of newrole? The first two cases look exactly identical to newrole btw - it just gets an error from security_check_context() telling it that the context wasn't valid, not why. > What other SE Linux programs are > considered "trusted" and require audit messages when they fail to be used > properly? The only other program that I can think of that is audit enhanced > is semanage. semodule came up recently (in order to distinguish different module operations at finer granularity than the kernel can see). -- Stephen Smalley National Security Agency From sgrubb at redhat.com Fri Sep 15 19:36:49 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 15 Sep 2006 15:36:49 -0400 Subject: [redhat-lspp] Newrole failure yeilds no audit record In-Reply-To: <1158348505.18951.130.camel@moss-spartans.epoch.ncsc.mil> References: <4509BF1C.7070603@us.ibm.com> <200609151516.08100.sgrubb@redhat.com> <1158348505.18951.130.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <200609151536.49217.sgrubb@redhat.com> On Friday 15 September 2006 15:28, Stephen Smalley wrote: > Are you sure? ?What do you want to audit? > newrole -r typoinrolename ? > newrole -r sysadm_r for user not authorized for that role? > any error exit path out of newrole? > > The first two cases look exactly identical to newrole btw - it just gets > an error from security_check_context() telling it that the context > wasn't valid, not why. I think we only need to say that the result was a failure. We do not need to say why it failed. > > ? What other SE Linux programs are considered "trusted" and require audit > > ? messages when they fail to be used properly? The only other program that > > ? I can think of that is audit enhanced is semanage. > > semodule came up recently (in order to distinguish different module > operations at finer granularity than the kernel can see). OK, I guess we'll look at that too. -Steve From Valdis.Kletnieks at vt.edu Fri Sep 15 19:57:34 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 15 Sep 2006 15:57:34 -0400 Subject: [redhat-lspp] Newrole failure yeilds no audit record In-Reply-To: Your message of "Fri, 15 Sep 2006 15:36:49 EDT." <200609151536.49217.sgrubb@redhat.com> References: <4509BF1C.7070603@us.ibm.com> <200609151516.08100.sgrubb@redhat.com> <1158348505.18951.130.camel@moss-spartans.epoch.ncsc.mil> <200609151536.49217.sgrubb@redhat.com> Message-ID: <200609151957.k8FJvYHG026324@turing-police.cc.vt.edu> On Fri, 15 Sep 2006 15:36:49 EDT, Steve Grubb said: > On Friday 15 September 2006 15:28, Stephen Smalley wrote: > > Are you sure? ??What do you want to audit? > > newrole -r typoinrolename ? > > newrole -r sysadm_r for user not authorized for that role? > > any error exit path out of newrole? > > > > The first two cases look exactly identical to newrole btw - it just gets > > an error from security_check_context() telling it that the context > > wasn't valid, not why. > > I think we only need to say that the result was a failure. We do not need to > say why it failed. Does it make sense to just log what information we *do* know, and hope there's enough for a human to tell what happened? Or does this run into the same sort of data-disclosure issues that logging the userid on invalid password attempts has (namely, that if the user has gotten "out of sync", they may type their password in response to the Userid: prompt and cause it to be logged in cleartext). Or should security_check_context() return a more featureful return code in case of an error? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sds at tycho.nsa.gov Fri Sep 15 20:32:56 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 15 Sep 2006 16:32:56 -0400 Subject: [redhat-lspp] Re: Question on type_member rule In-Reply-To: References: <1158342058.18951.85.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1158352376.18951.174.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-09-15 at 15:23 -0400, Rosalie Hiebel wrote: > Thanks very much for the explanation of how the context of instance > directories is computed. Once I added the proper type_member rule, > it was working as you described. Ok, good. > I want an application which runs at various MLS levels to see only > the instance whose MLS level matches the process's MLS level; I > thought polyinstantiation by context would easily provide this. If the application is security-aware and knows what level it is operating in, it could just directly manage and access the proper per-level instance directories. No need to have it transparently created and mounted in that situation. Now, if the main application itself is security-aware, but you want it to launch sub-applications that are untrusted and security-unaware, then the main application could very well use pam_namespace to set up the namespace in the child process prior to exec'ing the sub-application in the desired level. That would provide transparency to the sub-applications as well as providing stronger isolation than doing everything in the main application. > We > also would occasionally like certain processes to be able to see all > instances of it at or below the MLS level of the process. Is this > possible with polyinstantiation? (Would the user being in the list > of excluded uids be required?) I think there are different options here, e.g.: - put the user in the exclusion list to avoid creating a separate namespace altogether, or - directly access the instance directories if they live outside of the polyinstantiated directory (as per namespace.conf), or - unmount any bind mounts from the current namespace in order to see the instance directories if they live within the polyinstantiated directory. Or just create the process outside of anything that uses pam_namespace. -- Stephen Smalley National Security Agency From ltcgcw at us.ibm.com Mon Sep 18 04:56:36 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Sun, 17 Sep 2006 23:56:36 -0500 Subject: [redhat-lspp] [Reminder] Open LSPP Development Telecon Mon., Sept. 18 Message-ID: <20060918045636.GA12890@us.ibm.com> IBM hosts a telecon every Monday at 20:00 UTC to discuss the development issues surrounding Linux LSPP certification. The call is open to all who have something to bring to the effort. If you would like to participate and are not already an attendee, please reply directly to me with your contact information. I will respond with an invitation. Please note that the number of attendees may be limited by our call center's restrictions on maximum lines per conference. -- George Wilson IBM Linux Technology Center From latten at austin.ibm.com Mon Sep 18 23:02:35 2006 From: latten at austin.ibm.com (Joy Latten) Date: Mon, 18 Sep 2006 18:02:35 -0500 Subject: [redhat-lspp] racoon patch Message-ID: <200609182302.k8IN2Zfu006200@faith.austin.ibm.com> The following adds Venkat's changes to racoon to understand mls label. I have not yet thoroughly tested this patch. I have played with it a little and have found that racoon won't establish an SA when using ipsec without labels. The function, within_range() appears to always assume there is a label. I am currently working on fixing this. If you have any problems with this patch, please let me know. Basic steps to use: 1. This patch is against ipsec-tools-0.6.5.3-1 source in latest rawhide. 2. To patch source: install ipsec-tools-0.6.5.3-1.src.rpm cd to /usr/src/redhat rpmbuild -bp SPECS/ipsec-tools.spec cd BUILD/ipsec-tools-0.6.5 patch -p1 < 3. To build ipsec-tools ./bootstrap ./configure make 4. install new binary into /usr/local/sbin/racoon cp src/racoon /usr/local/sbin/racoon 5. to run new racoon, you must also specify location of config file since we did not build with redhat default of /etc/racoon. /usr/local/sbin/racoon -f /etc/racoon/racoon.conf 6. Some config info: You must first add policies to the policy database in order for racoon to know to establish SAs for a particular traffic stream. For example: in the file /tmp/setkey.nolabel I have the following info to create policies without labels. spdadd 10.1.0.55 10.1.0.206 any -P in ipsec esp/transport//require; spdadd 10.1.0.206 10.1.0.55 any -P out ipsec esp/transport//require; OR in the file /tmp/setkey.label I have the following info to create policy with labels. spdadd 10.1.0.55 10.1.0.206 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P in ipsec esp/transport//require; spdadd 9.3.192.206 9.3.189.55 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P out ipsec esp/transport//require; NEXT run "setkey -f /tmp/setkey.nolabel" to establish policy without labels OR run "setkey -f /tmp/setkey.label" to establish policy with a label. NEXT Now you need to configure racoon. For a simple config, I use pre-shared keys with a very basic racoon configuration. The two files i will use are psk.txt for preshared keys and racoon's basic config file, racoon.conf. For example: I first add the following to /etc/racoon/psk.txt, (please add whatever text you want for your shared secret key. In this example, I used "flibbertigibbet".) 10.1.0.55 flibbertigibbet 10.1.0.206 flibbertigibbet In /etc/racoon/racoon.conf, I pretty much use the defaults. I have the following in my /etc/racoon/racoon.conf: path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs"; sainfo anonymous { pfs_group 2; lifetime time 1 hour ; encryption_algorithm 3des, aes ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } NEXT You can now start racoon daemon. On command line issue, /usr/local/sbin/racoon -f /etc/racoon/racoon.conf This should do it. Let me know if you have any problems. Regards, Joy Latten --------------------------------------------------------------------------- diff -urpN ipsec-tools-0.6.5.orig/configure.ac ipsec-tools-0.6.5.0918/configure.ac --- ipsec-tools-0.6.5.orig/configure.ac 2006-08-22 00:49:52.000000000 -0500 +++ ipsec-tools-0.6.5.0918/configure.ac 2006-09-18 03:29:40.000000000 -0500 @@ -620,6 +620,7 @@ if test "$enable_security_context" = "ye AC_DEFINE([HAVE_SECCTX], [], [Enable Security Context]) SECCTX_OBJS="security.o" AC_SUBST(SECCTX_OBJS) + LIBS="$LIBS -lselinux" fi fi diff -urpN ipsec-tools-0.6.5.orig/src/racoon/cftoken.c ipsec-tools-0.6.5.0918/src/racoon/cftoken.c --- ipsec-tools-0.6.5.orig/src/racoon/cftoken.c 2006-08-22 00:49:52.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/cftoken.c 2006-09-18 02:57:23.000000000 -0500 @@ -1363,6 +1363,7 @@ char *yytext; #include "isakmp_var.h" #include "isakmp.h" #include "ipsec_doi.h" +#include "policy.h" #include "proposal.h" #include "nattraversal.h" #ifdef GC diff -urpN ipsec-tools-0.6.5.orig/src/racoon/isakmp_quick.c ipsec-tools-0.6.5.0918/src/racoon/isakmp_quick.c --- ipsec-tools-0.6.5.orig/src/racoon/isakmp_quick.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/isakmp_quick.c 2006-09-18 02:47:16.000000000 -0500 @@ -2128,5 +2128,11 @@ get_proposal_r(iph2) return ISAKMP_INTERNAL_ERROR; } +#ifdef HAVE_SECCTX + if (spidx.sec_ctx.ctx_str) { + set_secctx_in_proposal(iph2, spidx); + } +#endif /* HAVE_SECCTX */ + return 0; } diff -urpN ipsec-tools-0.6.5.orig/src/racoon/pfkey.c ipsec-tools-0.6.5.0918/src/racoon/pfkey.c --- ipsec-tools-0.6.5.orig/src/racoon/pfkey.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/pfkey.c 2006-09-18 03:04:00.000000000 -0500 @@ -1672,6 +1672,10 @@ pk_recvacquire(mhp) struct ph2handle *iph2[MAXNESTEDSA]; struct sockaddr *src, *dst; int n; /* # of phase 2 handler */ +#ifdef HAVE_SECCTX + struct sadb_x_sec_ctx *m_sec_ctx; +#endif /* HAVE_SECCTX */ + struct policyindex spidx; /* ignore this message because of local test mode. */ if (f_local) @@ -1691,6 +1695,24 @@ pk_recvacquire(mhp) src = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_SRC]); dst = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_DST]); +#ifdef HAVE_SECCTX + m_sec_ctx = (struct sadb_x_sec_ctx *)mhp[SADB_X_EXT_SEC_CTX]; + + if (m_sec_ctx != NULL) { + plog(LLV_INFO, LOCATION, NULL, + "security context doi: %u\n", + m_sec_ctx->sadb_x_ctx_doi); + plog(LLV_INFO, LOCATION, NULL, + "security context algorithm: %u\n", + m_sec_ctx->sadb_x_ctx_alg); + plog(LLV_INFO, LOCATION, NULL, + "security context length: %u\n", + m_sec_ctx->sadb_x_ctx_len); + plog(LLV_INFO, LOCATION, NULL, "security context: %s\n", + ((char *)m_sec_ctx + sizeof(struct sadb_x_sec_ctx))); + } +#endif /* HAVE_SECCTX */ + /* ignore if type is not IPSEC_POLICY_IPSEC */ if (xpl->sadb_x_policy_type != IPSEC_POLICY_IPSEC) { plog(LLV_DEBUG, LOCATION, NULL, @@ -1778,7 +1800,6 @@ pk_recvacquire(mhp) /* get inbound policy */ { - struct policyindex spidx; spidx.dir = IPSEC_DIR_INBOUND; memcpy(&spidx.src, &sp_out->spidx.dst, sizeof(spidx.src)); @@ -1786,10 +1807,16 @@ pk_recvacquire(mhp) spidx.prefs = sp_out->spidx.prefd; spidx.prefd = sp_out->spidx.prefs; spidx.ul_proto = sp_out->spidx.ul_proto; + #ifdef HAVE_SECCTX - if (*sp_out->spidx.sec_ctx.ctx_str) - memcpy(&spidx.sec_ctx, &sp_out->spidx.sec_ctx, - sizeof(spidx.sec_ctx)); + if (m_sec_ctx) { + spidx.sec_ctx.ctx_doi = m_sec_ctx->sadb_x_ctx_doi; + spidx.sec_ctx.ctx_alg = m_sec_ctx->sadb_x_ctx_alg; + spidx.sec_ctx.ctx_strlen = m_sec_ctx->sadb_x_ctx_len; + memcpy(spidx.sec_ctx.ctx_str, + ((char *)m_sec_ctx + sizeof(struct sadb_x_sec_ctx)), + spidx.sec_ctx.ctx_strlen); + } #endif sp_in = getsp(&spidx); @@ -1877,6 +1904,12 @@ pk_recvacquire(mhp) delph2(iph2[n]); return -1; } +#ifdef HAVE_SECCTX + if (m_sec_ctx) { + set_secctx_in_proposal(iph2[n], spidx); + } +#endif /* HAVE_SECCTX */ + insph2(iph2[n]); /* start isakmp initiation by using ident exchange */ diff -urpN ipsec-tools-0.6.5.orig/src/racoon/policy.c ipsec-tools-0.6.5.0918/src/racoon/policy.c --- ipsec-tools-0.6.5.orig/src/racoon/policy.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/policy.c 2006-09-18 02:47:16.000000000 -0500 @@ -206,9 +206,13 @@ cmpspidxstrict(a, b) #ifdef HAVE_SECCTX if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi +#if 1 + || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) +#else || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, a->sec_ctx.ctx_strlen) != 0)) +#endif return 1; #endif return 0; @@ -284,9 +288,13 @@ cmpspidxwild(a, b) #ifdef HAVE_SECCTX if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi +#if 1 + || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) +#else || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, a->sec_ctx.ctx_strlen) != 0)) +#endif return 1; #endif diff -urpN ipsec-tools-0.6.5.orig/src/racoon/policy.h ipsec-tools-0.6.5.0918/src/racoon/policy.h --- ipsec-tools-0.6.5.orig/src/racoon/policy.h 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/policy.h 2006-09-18 03:05:08.000000000 -0500 @@ -35,6 +35,7 @@ #include #ifdef HAVE_SECCTX + #define MAX_CTXSTR_SIZE 50 struct security_ctx { u_int8_t ctx_doi; /* Security Context DOI */ @@ -146,6 +147,11 @@ extern void initsp __P((void)); extern struct ipsecrequest *newipsecreq __P((void)); extern const char *spidx2str __P((const struct policyindex *)); +#ifdef HAVE_SECCTX +#include extern int get_security_context __P((vchar_t *, struct policyindex *)); +extern int within_range __P((security_context_t, security_context_t)); +extern void set_secctx_in_proposal __P((struct ph2handle *, struct policyindex)); +#endif #endif /* _POLICY_H */ diff -urpN ipsec-tools-0.6.5.orig/src/racoon/proposal.c ipsec-tools-0.6.5.0918/src/racoon/proposal.c --- ipsec-tools-0.6.5.orig/src/racoon/proposal.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/proposal.c 2006-09-18 02:47:16.000000000 -0500 @@ -1025,15 +1025,6 @@ set_proposal_from_policy(iph2, sp_main, newpp->lifetime = iph2->sainfo->lifetime; newpp->lifebyte = iph2->sainfo->lifebyte; newpp->pfs_group = iph2->sainfo->pfs_group; -#ifdef HAVE_SECCTX - if (*sp_main->spidx.sec_ctx.ctx_str) { - newpp->sctx.ctx_doi = sp_main->spidx.sec_ctx.ctx_doi; - newpp->sctx.ctx_alg = sp_main->spidx.sec_ctx.ctx_alg; - newpp->sctx.ctx_strlen = sp_main->spidx.sec_ctx.ctx_strlen; - memcpy(newpp->sctx.ctx_str, sp_main->spidx.sec_ctx.ctx_str, - sp_main->spidx.sec_ctx.ctx_strlen); - } -#endif /* HAVE_SECCTX */ if (lcconf->complex_bundle) goto skip1; @@ -1196,7 +1187,11 @@ set_proposal_from_proposal(iph2) pp0->sctx.ctx_strlen = pp_peer->sctx.ctx_strlen; memcpy(pp0->sctx.ctx_str, pp_peer->sctx.ctx_str, pp_peer->sctx.ctx_strlen); + + plog(LLV_INFO, LOCATION, NULL, + "RESPONDING with (%s).\n", pp_peer->sctx.ctx_str); } + #endif /* HAVE_SECCTX */ if (pp_peer->next != NULL) { diff -urpN ipsec-tools-0.6.5.orig/src/racoon/security.c ipsec-tools-0.6.5.0918/src/racoon/security.c --- ipsec-tools-0.6.5.orig/src/racoon/security.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/security.c 2006-09-18 03:06:42.000000000 -0500 @@ -1,5 +1,6 @@ /* * Copyright (C) 2005 International Business Machines Corporation + * Copyright (c) 2005 by Trusted Computer Solutions, Inc. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -36,6 +37,12 @@ #include #include +#include +#include +#include +#include +#include + #include "var.h" #include "vmbuf.h" #include "misc.h" @@ -45,6 +52,7 @@ #include "isakmp.h" #include "ipsec_doi.h" #include "policy.h" +#include "proposal.h" #include "strnames.h" #include "handler.h" @@ -150,3 +158,109 @@ get_security_context(sa, p) } return 0; } + +void +set_secctx_in_proposal(iph2, spidx) + struct ph2handle *iph2; + struct policyindex spidx; +{ + iph2->proposal->sctx.ctx_doi = spidx.sec_ctx.ctx_doi; + iph2->proposal->sctx.ctx_alg = spidx.sec_ctx.ctx_alg; + iph2->proposal->sctx.ctx_strlen = spidx.sec_ctx.ctx_strlen; + memcpy(iph2->proposal->sctx.ctx_str, spidx.sec_ctx.ctx_str, + spidx.sec_ctx.ctx_strlen); +} + + +/* + * function: init_avc + * description: function performs the steps necessary to initialize the + * userspace avc. + * input: void + * return: 0 if avc was successfully initialized + * 1 if the avc could not be initialized + */ + +static int +init_avc(void) +{ + int rtn = 0; + + if (!is_selinux_mls_enabled()) { + plog(LLV_ERROR, LOCATION, NULL, "racoon: MLS support is not" + " enabled.\n"); + return 1; + } + + rtn = avc_init("racoon", NULL, NULL, NULL, NULL); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, "racoon: could not initialize avc.\n"); + rtn = 1; + } + return rtn; +} + +/* + * function: within_range + * description: function determines if the specified sl is within the + * configured range for a policy rule. + * input: security_context *sl SL + * char *range Range + * return: 1 if the sl is within the range + * 0 if the sl is not within the range or an error + * occurred which prevented the determination + */ + +int +within_range(security_context_t sl, security_context_t range) +{ + int rtn = 1; + security_id_t slsid; + security_id_t rangesid; + struct av_decision avd; + security_class_t tclass; + access_vector_t av; + + rtn = init_avc(); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: couldn't initialize the AVC\n"); + return 0; + } + + /* + * Get the sids for the sl and range contexts + */ + rtn = avc_context_to_sid(sl, &slsid); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: Unable to retrieve " + "sid for sl context (%s).\n", sl); + return 0; + } + rtn = avc_context_to_sid(range, &rangesid); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: Unable to retrieve " + "sid for range context (%s).\n", range); + sidput(slsid); + return 0; + } + + /* + * Straight up test between sl and range + */ + tclass = SECCLASS_ASSOCIATION; + av = ASSOCIATION__POLMATCH; + rtn = avc_has_perm(slsid, rangesid, tclass, av, NULL, &avd); + if (rtn != 0) { + plog(LLV_INFO, LOCATION, NULL, + "within_range: The sl is not within range\n"); + sidput(slsid); + sidput(rangesid); + return 0; + } + plog(LLV_DEBUG, LOCATION, NULL, + "within_range: The sl (%s) is within range (%s)\n", sl, range); + return 1; +} From loulwas at us.ibm.com Mon Sep 18 23:26:37 2006 From: loulwas at us.ibm.com (Loulwa Salem) Date: Mon, 18 Sep 2006 18:26:37 -0500 Subject: [redhat-lspp] LSPP Development Telecon 09/18/2006 Minutes Message-ID: <450F2B2D.3090105@us.ibm.com> Note: I think I mixed up people's voices today, so apologies for that. Feel free to correct me if I mentioned you said something you actually didn't 09/18/2006 lspp Meeting Minutes: =============================== Attendees Robin Redden (IBM) - RR George Wilson (IBM) - GW Loulwa Salem (IBM) - LS Michael Thompson (IBM) - MT Thiago Bauermann (IBM) - TB Al Viro (Red Hat) - AV Irina Boverman (Red Hat) - IB Steve Grubb (Red Hat) - SG Dan Walsh (Red Hat) - DW Linda Knippers (HP) - LK Amy Griffis (HP) - AG Matt Anderson (HP) - MA Paul Moore (HP) - PM Klaus Weidner (Atsec) - KW Darrel Goeddel (TCS) - DG Chad Hanson (TCS) - CH Venkat Yekkirala (TCS) - VY Joe Nall - JN Ted Toth - TT Bill O'Donnel - BO Tentative Agenda: Kernel / Rawhide update ------------------------ GW: Al, anything we need to know about the kernel? AV: no. there have been final patches given for hookups on targets into mainline kernel. All arch dependant changes are in mainline now. One question, do we care about stuff like solaris binaries? KW: yes we do care. if there is a way to disable these binaries. Main thing we don't want a user to run them without the admin able to stop them. AV: yes, there is a way to disable it KW: how do you recommend we do that? AV: disable them at build time KW: the problem is that people running the evaluated system don't build their own kernel. AV: there was alot of use for the binaries. there has been some support to at least a subset of syscalls. KW: is there an easy way to tell at run time which personalities are available for binaries? AV: yeah probably KW: ok, thanks AV: if we do implement this at some point, we'll need to think about adding those new audit fields. right now there is a constant for architecture and they really should be different. creation is not different, they should be just treated as separate archs. KW: I agree with treating them separate. main question is if people have interest. it's up to arch maintainer to see that audit works, so it might be a similar logic for this one. AV: this can be interesting. keep in mind it is not just kernel; user land has to understand those as well. GW: is this going to be an issue on rhel. can we prove to evaluator that binaries are not enabled? AV: This is not an immediate concern, maybe for future. really we'll best make sure those are disabled. I'll put it that way, I wouldn't rely on correctness of code. KW: maybe if people start adding this to the kernel then it'll be good to have one place to control it. AV: I don't think so. It is not a real concern. I don't believe anybody is using that on a production type system KW: what I was saying is that if it ever gets to a state where it is used, it would be good to have run time option to turn it on/off. GW: klaus we need to demonstrate that to evaluator? AV: which archs? GW: s390 and ... KW: RH doesn't ship with binary compatibility enabled. AV: we'll have support ... LK: the support for 32/64 is not in kernel by default AV: for audit enablement it shouldn't be a problem KW: it's not easy to test it actually works AV: handling of binaries is concerned on alpha, sparc and ... as far as I know. GW: sounds like we don't have a problem since these are not part of TOE. good news. AV: the kernel should be basically done GW: ok great. Any one has any more issue JN: I was having a problem with (a package?), what kernel is it in. Stephen smalley was saying it'll be in 2.6.19, but that's not the naming convention rhel is using? SG: those are release candidates, sort of mislabeled. it really is the 2.6.19 release candidate 7. JN: Ok, I was a bit confused and was trying to figure it out. SG: because of rpm, it is one version behind JN: when you ship it'll be 2.6.18? SG: yes. speaking of kernel, we have one bug (the audit by ppid problem). GW: does it still look like a user land problem? SG: can't tell. I ran pid and ppid value and it looks like it's builidng the same packages. other than that it's the kernel that evaluates that rule. As far as I can tell, user space is acting correctly, and so is the kernel AV: ..... SG: audit by ppid is only thing that doesn't work. AV: pid works? SG: audit by pid works, audit by ppid doesn't seem to work LK: is there a bugzilla for that SG: I asked mike to submit one MT: I submitted one, I'll check if it is on issue tracker SG: just so we get it, you can file against rawhide. as of Friday it is in sync with lspp kernel. I am looking for this bug, but it would help to have another set of eyes searching for it as well. AV: if you add negation which test does it take SG: if I negate it, it takes the proper one. It's really strange. I am building a new kernel to see how it gets evaluated AV: yeah, that's what I would do, to see what happens SG: yup GW: does this happen on all arch SG: on x86_64 MT: and ppc64 GW: alright, as for IPsec, I don't know if Joy had another ipsec patch out. MT: I have update from Joy, she said she sent a status update to lspp list about racoon. also a patch for ipsec, there is a bug in it, so she is currently working on fixing that and will send an updated patch. GW: has she posted a right up about that? MT: she said she'll add docs to what venkat sent out once she is done working on the bug. Not sure if that is what you were looking for? GW: It is .. great. ok, any other kernel issues? I know we need that networking section to test for bugs there as well. SELinux base update ------------------- GW: any selinux updates KW: one issue, selinux users mention that 256 categories is not sufficient. Any thing happening in there? DW: what number do you want GW: I believe it was mentioned to raise it to 1024 DW: we'll just update the policy, add the lines for the new categories. KW: I grepped for it, and found the limit mentioned in few places, so it is not only adding lines to policy I believe. DW: so we'll make it 1024. CH: great, because I currently exceeded that in some of my tests, so it's great that we are adding more categories. JN: I beleive there is a place where it is 239 limit in CIPSO. TT: you can have so many comparetments. The way netlabel gets around that, you can setup mapping, you can have one cipso DUI(?) that allows you to map certain ranges of levels. if you care about that, send me an e-mail and I'll show you examples. KW: what's the failure mode case. so that MLS restrictions are enforced? TT: if you can't guarantee labels on that. if you are doing accept it'll prevent you to write to that socket. KW: so it'll do the right things TT: hope so GW: looks like it need testing. I've seen a few other problems. There is no login prompt on console. Has anyone seen that? DW: after coming back from suspend mode? GW: no, on a fresh instal with MLS policy KW: is there an AVC message? GW: I need to check that MT: I've seen it happen as well GW: I'll test more, but just wanted to check it is not something I am doing before I open a bug DW: so on a fresh install you see it. sounds like a bug. GW: Another thing, if I create a user and try to change thier password, then I get a pam error. KW: there is a problem because of using the passwdqc module. that has been changed recently. DW: it is not selinux related, happens even in disabled mode. KW: there is a bug for that, kris opened it. This is not a very debugging friendly problem, the message is not very indicative of what's going on. TT: did you use useradd -m, that works for me. KW: the bug number is ( RH - issue tracker # 102108 ) GW: does every one have visibility to bugs IB: probably not, I only opened up one bug. I'll go through them and make them public. GW: ok, I have no objections to making them public IB: before we send them, I'll send list to IBM GW: Anyone sees more strange behavior? MLS policy issues ----------------- Audit userspace ---------------- GW: Steve, is there an update for audit user space? SG: I'll push audit-1.2.7 out overnight. to match 2.6.18 kerenel and various fix ups GW: should we pick it up through rawhide, or will there be an update repo SG: should be update repo, but not sure GW: ok, so we'll pick through rawhide. Thanks Steve Print ----- GW: Matt, how's print? MA: It's coming along. After seeing Rodrigo's message, I am a bit concerned, since previouly I didn't have access to usb printer. Now I have access to one, and I configured it through the graphical interface that came with rhel, so I am getting different info about the device. I am working on that, assuming all is cleared I plan to have an updated patch this week GW: great, thanks Matt. CIPSO ------ GW: Any CIPSO updates Paul? PM: working on finishing up a patch to change way of how net label uses netlink, to make it more consistent with kernel. all the code is basically written, but still looking through to debug. Few things popped up last week and I'll submit those fixes. also there is talk that I need to add audit messages to some places in the code to satisfy evaluation requirements. GW: what type will these be? PM: These will be shown when you configure netlabel. GW: will these be of new audit types PM: I imagine so, but I didn't get a chance to look at it closely. LK: this is to any security related changes to netlabel? PM: yes [Klaus came back with Pam bug number - conversation switched back to bugs tracking] IB: if you put lspp in subject line of the bug, then I'll pull it in my search and I'll make it public. if you are a member of our beta group, then you'll be able to see those bugs. Linda is a member, george is not for example. It's easier to make bugs public rather than to add everyone to the beta group GW: can you add me to beta group at least Irena, but I think it's good to make them public. My question, once there are change updates, how does the originator find out. IB: you won't get bug number, but you'll get the comments that people post. GW: Ok, that works IPsec ----- GW: so Micheal gave us Joy's status. Anyone from TCS or Venkat if on can give us further update. VY: I am on george. I am waiting on Joy's racoon patch to test that, then I'll send my kernel patch out. I heard that the version she sent out had a bug. CH: Venkat didn't hear what Mike said about Joy's status so I filled him in. MT: Joy said she had a patch, but it has a bug, that's what she is working on right now, she'll send an update to that patch with the fix VY: I'll test what I have and send my patch out. did she say when the fix will be sent? MT: She said "later" so I don't know exactly. GW: good idea to send what you have now. I'll talk to Joy and get a read on her status as well. IB: I am concerned how our fixes are going to make it to beta 2. Those patches need to be accepted by upstream and bugzillas opened so that they are managed by rhel as soon as possible in order for us to get them in. keep that in mind. GW: who need to open those IB: who ever is submitting those patches. maybe as soon as they submit to upstream, they need to create a bugzilla. so james morris knows what to look for and pull in. GW: Venkat, do you have an idea on when you'll be done VY: I am going to work on comments from Stephen smalley and I'll work on those and get those in next week or so. I'm planning that secmark patches being accepted. I'll get that in next couple of weeks. Need to get people to do design and docs. we had a question from Dan walch on how all of this is going to get integrated. I would guess in the next two to three weeks we'll have all those issues out of the way, and get buy in from people. SG: when you say couple of weeks, you mean 2 weeks? VY: I would say 2 to 3 weeks SG: we can't drag this after end of September, or they may not make it in beta 2 VY: for secmark that's a big one, we have some useful feedback now that we can act on. once we go through feedback, it's a matter of integrating it in and sending another set upstream. I say we are close for secmark, within next week we'll have issue resolved. I'll send the ipsec fix out tonight. DW: are you working on performance on secmark VY: We didn't check performance, just looking at functional right now DW: I just have usability concerns. I don't find secmark very usable. I don't like the interaction between policy and secmark. VY: I guess in next couple of days there will be a good amount of discussion on these aspects. DW: I heard there will be a big performance problem with loading iptable rules. this secmark stuff really need to be looked at GW: should we be using the compatibility mode then. may save us all a lot of headaches if we use the compatibility flag. DW: I just see huge problems with this, it is not very well thought out. the tools that generate secmark rules, they go through all ports. we have about 400 rules and you go through all of them before you go through ipsec rule that might drop the packet GW: problem is that it is coming in late. DW: the other problem is I'd like to have a tool that admins can run to set this thing up. GW: we need to keep an eye on that and have compat as backup plan SG: I have a feeling there is real good chance it won't make it VY: we'll have discussion in next couple of days. Dan already sent out email. GW: sounds like we are heading to compat use SG: I'll take action item to look in RH to see where that is going. GW: thanks Steve, and I'll do some research. thanks Venkat for the update. xinetd ------- GW: any issue with xinetd. anyone testing with it JN: we've been testing with it. the netlabel stuff doesn't work with unlabeled host just now CH: yes it does Joe. JN: in a reasonable plug it in and run, it's tough without policy modifications CH: yeah, you do need to do some policy work GW: sounds like we might need to make some testing on that. certainly need some end to end testing in our environment as well. ipsec-tools: SPD dump and racoon base + MLS --------------------------------------------- GW: I'll get hold of Joy and see what's happening with the bugs and get more documentation from her as well. Single-user mode ----------------- GW: did single user mode make it? DW: I'll have to check Self tests ----------- GW: I have done nothing on, had some personal issues to attend to. VFS polyinstantiation ---------------------- GW: don't know anything on those. anyone has update on newrole issue. there was debate on selinux, might have been resolved but I didn't follow it. DW: it is not resolved as far as I know. CH: folks are working on it are writing up their issues. GW: write bugzillas and submit to list. if we don't get visibility for bugs, then write a note to list. so we are not all hitting the same problem and writing same bugs. I appreciate you doing the testing. if they are minor issues, we might be able to bug janak with them. GW: any other issues, if not we'll adjourn meeting. Thanks everyone. Cron, tmpwatch, mail, etc. -------------------------- Bugs / remaining tasks ----------------------- Final cutoff date ----------------- From latten at austin.ibm.com Tue Sep 19 03:17:21 2006 From: latten at austin.ibm.com (Joy Latten) Date: Mon, 18 Sep 2006 22:17:21 -0500 Subject: [redhat-lspp] improved racoon patch and instructions Message-ID: <200609190317.k8J3HL5F007346@faith.austin.ibm.com> I have found and fixed the bug that prevented racoon from establishing SAs that were not labeled. I have included additional instructions on how to configure ipsec and racoon. I consider this patch and its instructions an improvement from that which I sent earlier this evening. Please use this patch and these instructions. I will run a stress test with ipsec & racoon without labels tonight. So far, test efforts have been to ensure regular ipsec behaviour has not regressed. I am running with mls policy in permissive on rawhide kernel from last week, I believe. Tomorrow I will test with labels. If you have any problems with this patch, please let me know. Basic steps to use: 1. This patch is against ipsec-tools-0.6.5.3-1 source in latest rawhide. 2. To patch source: install ipsec-tools-0.6.5.3-1.src.rpm cd to /usr/src/redhat rpmbuild -bp SPECS/ipsec-tools.spec cd BUILD/ipsec-tools-0.6.5 patch -p1 < 3. To build ipsec-tools ./bootstrap ./configure make 4. install new binary into /usr/local/sbin/racoon cp src/racoon /usr/local/sbin/racoon 5. See next step if you would like info on configuring racoon. You must configure before running. To run new racoon, you must also specify location of config file since we did not build with redhat default of /etc/racoon. /usr/local/sbin/racoon -f /etc/racoon/racoon.conf 6. Some config info: You must first add policies to the policy database in order for racoon to know to establish SAs for a particular traffic stream. For example: in the file /tmp/setkey.nolabel I have the following info to create policies without labels. spdadd 10.1.0.55 10.1.0.206 any -P in ipsec esp/transport//require; spdadd 10.1.0.206 10.1.0.55 any -P out ipsec esp/transport//require; OR in the file /tmp/setkey.label I have the following info to create policy with labels. spdadd 10.1.0.55 10.1.0.206 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P in ipsec esp/transport//require; spdadd 9.3.192.206 9.3.189.55 any -ctx 1 1 "system_u:object_r:unlabeled_t:s0:c0" -P out ipsec esp/transport//require; NEXT run "setkey -f /tmp/setkey.nolabel" to add policy without labels OR run "setkey -f /tmp/setkey.label" to add policy with a label. NEXT Now you need to configure racoon. For a simple config, I use pre-shared keys with a very basic racoon configuration. The two files i will use are psk.txt for preshared keys and racoon's basic config file, racoon.conf. For example: I first add the following to /etc/racoon/psk.txt, (please add whatever text you want for your shared secret key. In this example, I used "flibbertigibbet".) 10.1.0.55 flibbertigibbet 10.1.0.206 flibbertigibbet In /etc/racoon/racoon.conf, I pretty much use the defaults. I have the following in my /etc/racoon/racoon.conf: path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs"; remote anonymous { exchange_mode main,aggressive; doi ipsec_doi; nonce_size 16; lifetime time 24 hour; proposal_check obey; proposal { encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2; } } sainfo anonymous { pfs_group 2; lifetime time 6 hour ; encryption_algorithm 3des, aes ; authentication_algorithm hmac_sha1, hmac_md5 ; compression_algorithm deflate ; } NEXT You can now start racoon daemon. On command line issue, /usr/local/sbin/racoon -f /etc/racoon/racoon.conf NOTE: To stop racoon daemon, do "kill . This will remove the SAs from the kernel. "setkey -FP" will remove the policy from the kernel. This should do it. Let me know if you have any problems. Regards, Joy Latten --------------------------------------------------------------------------- diff -urpN ipsec-tools-0.6.5.orig/configure.ac ipsec-tools-0.6.5.0918/configure.ac --- ipsec-tools-0.6.5.orig/configure.ac 2006-08-22 00:49:52.000000000 -0500 +++ ipsec-tools-0.6.5.0918/configure.ac 2006-09-18 03:29:40.000000000 -0500 @@ -620,6 +620,7 @@ if test "$enable_security_context" = "ye AC_DEFINE([HAVE_SECCTX], [], [Enable Security Context]) SECCTX_OBJS="security.o" AC_SUBST(SECCTX_OBJS) + LIBS="$LIBS -lselinux" fi fi diff -urpN ipsec-tools-0.6.5.orig/src/racoon/cftoken.c ipsec-tools-0.6.5.0918/src/racoon/cftoken.c --- ipsec-tools-0.6.5.orig/src/racoon/cftoken.c 2006-08-22 00:49:52.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/cftoken.c 2006-09-18 02:57:23.000000000 -0500 @@ -1363,6 +1363,7 @@ char *yytext; #include "isakmp_var.h" #include "isakmp.h" #include "ipsec_doi.h" +#include "policy.h" #include "proposal.h" #include "nattraversal.h" #ifdef GC diff -urpN ipsec-tools-0.6.5.orig/src/racoon/isakmp_quick.c ipsec-tools-0.6.5.0918/src/racoon/isakmp_quick.c --- ipsec-tools-0.6.5.orig/src/racoon/isakmp_quick.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/isakmp_quick.c 2006-09-18 02:47:16.000000000 -0500 @@ -2128,5 +2128,11 @@ get_proposal_r(iph2) return ISAKMP_INTERNAL_ERROR; } +#ifdef HAVE_SECCTX + if (spidx.sec_ctx.ctx_str) { + set_secctx_in_proposal(iph2, spidx); + } +#endif /* HAVE_SECCTX */ + return 0; } diff -urpN ipsec-tools-0.6.5.orig/src/racoon/pfkey.c ipsec-tools-0.6.5.0918/src/racoon/pfkey.c --- ipsec-tools-0.6.5.orig/src/racoon/pfkey.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/pfkey.c 2006-09-18 03:04:00.000000000 -0500 @@ -1672,6 +1672,10 @@ pk_recvacquire(mhp) struct ph2handle *iph2[MAXNESTEDSA]; struct sockaddr *src, *dst; int n; /* # of phase 2 handler */ +#ifdef HAVE_SECCTX + struct sadb_x_sec_ctx *m_sec_ctx; +#endif /* HAVE_SECCTX */ + struct policyindex spidx; /* ignore this message because of local test mode. */ if (f_local) @@ -1691,6 +1695,24 @@ pk_recvacquire(mhp) src = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_SRC]); dst = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_DST]); +#ifdef HAVE_SECCTX + m_sec_ctx = (struct sadb_x_sec_ctx *)mhp[SADB_X_EXT_SEC_CTX]; + + if (m_sec_ctx != NULL) { + plog(LLV_INFO, LOCATION, NULL, + "security context doi: %u\n", + m_sec_ctx->sadb_x_ctx_doi); + plog(LLV_INFO, LOCATION, NULL, + "security context algorithm: %u\n", + m_sec_ctx->sadb_x_ctx_alg); + plog(LLV_INFO, LOCATION, NULL, + "security context length: %u\n", + m_sec_ctx->sadb_x_ctx_len); + plog(LLV_INFO, LOCATION, NULL, "security context: %s\n", + ((char *)m_sec_ctx + sizeof(struct sadb_x_sec_ctx))); + } +#endif /* HAVE_SECCTX */ + /* ignore if type is not IPSEC_POLICY_IPSEC */ if (xpl->sadb_x_policy_type != IPSEC_POLICY_IPSEC) { plog(LLV_DEBUG, LOCATION, NULL, @@ -1778,7 +1800,6 @@ pk_recvacquire(mhp) /* get inbound policy */ { - struct policyindex spidx; spidx.dir = IPSEC_DIR_INBOUND; memcpy(&spidx.src, &sp_out->spidx.dst, sizeof(spidx.src)); @@ -1786,10 +1807,16 @@ pk_recvacquire(mhp) spidx.prefs = sp_out->spidx.prefd; spidx.prefd = sp_out->spidx.prefs; spidx.ul_proto = sp_out->spidx.ul_proto; + #ifdef HAVE_SECCTX - if (*sp_out->spidx.sec_ctx.ctx_str) - memcpy(&spidx.sec_ctx, &sp_out->spidx.sec_ctx, - sizeof(spidx.sec_ctx)); + if (m_sec_ctx) { + spidx.sec_ctx.ctx_doi = m_sec_ctx->sadb_x_ctx_doi; + spidx.sec_ctx.ctx_alg = m_sec_ctx->sadb_x_ctx_alg; + spidx.sec_ctx.ctx_strlen = m_sec_ctx->sadb_x_ctx_len; + memcpy(spidx.sec_ctx.ctx_str, + ((char *)m_sec_ctx + sizeof(struct sadb_x_sec_ctx)), + spidx.sec_ctx.ctx_strlen); + } #endif sp_in = getsp(&spidx); @@ -1877,6 +1904,12 @@ pk_recvacquire(mhp) delph2(iph2[n]); return -1; } +#ifdef HAVE_SECCTX + if (m_sec_ctx) { + set_secctx_in_proposal(iph2[n], spidx); + } +#endif /* HAVE_SECCTX */ + insph2(iph2[n]); /* start isakmp initiation by using ident exchange */ diff -urpN ipsec-tools-0.6.5.orig/src/racoon/policy.c ipsec-tools-0.6.5.0918/src/racoon/policy.c --- ipsec-tools-0.6.5.orig/src/racoon/policy.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/policy.c 2006-09-18 02:47:16.000000000 -0500 @@ -206,9 +206,13 @@ cmpspidxstrict(a, b) #ifdef HAVE_SECCTX if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi +#if 1 + || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) +#else || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, a->sec_ctx.ctx_strlen) != 0)) +#endif return 1; #endif return 0; @@ -284,9 +288,13 @@ cmpspidxwild(a, b) #ifdef HAVE_SECCTX if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi +#if 1 + || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) +#else || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, a->sec_ctx.ctx_strlen) != 0)) +#endif return 1; #endif diff -urpN ipsec-tools-0.6.5.orig/src/racoon/policy.h ipsec-tools-0.6.5.0918/src/racoon/policy.h --- ipsec-tools-0.6.5.orig/src/racoon/policy.h 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/policy.h 2006-09-18 03:05:08.000000000 -0500 @@ -35,6 +35,7 @@ #include #ifdef HAVE_SECCTX + #define MAX_CTXSTR_SIZE 50 struct security_ctx { u_int8_t ctx_doi; /* Security Context DOI */ @@ -146,6 +147,11 @@ extern void initsp __P((void)); extern struct ipsecrequest *newipsecreq __P((void)); extern const char *spidx2str __P((const struct policyindex *)); +#ifdef HAVE_SECCTX +#include extern int get_security_context __P((vchar_t *, struct policyindex *)); +extern int within_range __P((security_context_t, security_context_t)); +extern void set_secctx_in_proposal __P((struct ph2handle *, struct policyindex)); +#endif #endif /* _POLICY_H */ diff -urpN ipsec-tools-0.6.5.orig/src/racoon/proposal.c ipsec-tools-0.6.5.0918/src/racoon/proposal.c --- ipsec-tools-0.6.5.orig/src/racoon/proposal.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/proposal.c 2006-09-18 02:47:16.000000000 -0500 @@ -1025,15 +1025,6 @@ set_proposal_from_policy(iph2, sp_main, newpp->lifetime = iph2->sainfo->lifetime; newpp->lifebyte = iph2->sainfo->lifebyte; newpp->pfs_group = iph2->sainfo->pfs_group; -#ifdef HAVE_SECCTX - if (*sp_main->spidx.sec_ctx.ctx_str) { - newpp->sctx.ctx_doi = sp_main->spidx.sec_ctx.ctx_doi; - newpp->sctx.ctx_alg = sp_main->spidx.sec_ctx.ctx_alg; - newpp->sctx.ctx_strlen = sp_main->spidx.sec_ctx.ctx_strlen; - memcpy(newpp->sctx.ctx_str, sp_main->spidx.sec_ctx.ctx_str, - sp_main->spidx.sec_ctx.ctx_strlen); - } -#endif /* HAVE_SECCTX */ if (lcconf->complex_bundle) goto skip1; @@ -1196,7 +1187,11 @@ set_proposal_from_proposal(iph2) pp0->sctx.ctx_strlen = pp_peer->sctx.ctx_strlen; memcpy(pp0->sctx.ctx_str, pp_peer->sctx.ctx_str, pp_peer->sctx.ctx_strlen); + + plog(LLV_INFO, LOCATION, NULL, + "RESPONDING with (%s).\n", pp_peer->sctx.ctx_str); } + #endif /* HAVE_SECCTX */ if (pp_peer->next != NULL) { diff -urpN ipsec-tools-0.6.5.orig/src/racoon/security.c ipsec-tools-0.6.5.0918/src/racoon/security.c --- ipsec-tools-0.6.5.orig/src/racoon/security.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/security.c 2006-09-18 10:58:37.000000000 -0500 @@ -1,5 +1,6 @@ /* * Copyright (C) 2005 International Business Machines Corporation + * Copyright (c) 2005 by Trusted Computer Solutions, Inc. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -36,6 +37,12 @@ #include #include +#include +#include +#include +#include +#include + #include "var.h" #include "vmbuf.h" #include "misc.h" @@ -45,6 +52,7 @@ #include "isakmp.h" #include "ipsec_doi.h" #include "policy.h" +#include "proposal.h" #include "strnames.h" #include "handler.h" @@ -150,3 +158,112 @@ get_security_context(sa, p) } return 0; } + +void +set_secctx_in_proposal(iph2, spidx) + struct ph2handle *iph2; + struct policyindex spidx; +{ + iph2->proposal->sctx.ctx_doi = spidx.sec_ctx.ctx_doi; + iph2->proposal->sctx.ctx_alg = spidx.sec_ctx.ctx_alg; + iph2->proposal->sctx.ctx_strlen = spidx.sec_ctx.ctx_strlen; + memcpy(iph2->proposal->sctx.ctx_str, spidx.sec_ctx.ctx_str, + spidx.sec_ctx.ctx_strlen); +} + + +/* + * function: init_avc + * description: function performs the steps necessary to initialize the + * userspace avc. + * input: void + * return: 0 if avc was successfully initialized + * 1 if the avc could not be initialized + */ + +static int +init_avc(void) +{ + int rtn = 0; + + if (!is_selinux_mls_enabled()) { + plog(LLV_ERROR, LOCATION, NULL, "racoon: MLS support is not" + " enabled.\n"); + return 1; + } + + rtn = avc_init("racoon", NULL, NULL, NULL, NULL); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, "racoon: could not initialize avc.\n"); + rtn = 1; + } + return rtn; +} + +/* + * function: within_range + * description: function determines if the specified sl is within the + * configured range for a policy rule. + * input: security_context *sl SL + * char *range Range + * return: 1 if the sl is within the range + * 0 if the sl is not within the range or an error + * occurred which prevented the determination + */ + +int +within_range(security_context_t sl, security_context_t range) +{ + int rtn = 1; + security_id_t slsid; + security_id_t rangesid; + struct av_decision avd; + security_class_t tclass; + access_vector_t av; + + if (!*range) /* This policy doesn't have security context */ + return 1; + + rtn = init_avc(); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: couldn't initialize the AVC\n"); + return 0; + } + + /* + * Get the sids for the sl and range contexts + */ + rtn = avc_context_to_sid(sl, &slsid); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: Unable to retrieve " + "sid for sl context (%s).\n", sl); + return 0; + } + rtn = avc_context_to_sid(range, &rangesid); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: Unable to retrieve " + "sid for range context (%s).\n", range); + sidput(slsid); + return 0; + } + + /* + * Straight up test between sl and range + */ + tclass = SECCLASS_ASSOCIATION; + av = ASSOCIATION__POLMATCH; + rtn = avc_has_perm(slsid, rangesid, tclass, av, NULL, &avd); + if (rtn != 0) { + plog(LLV_INFO, LOCATION, NULL, + "within_range: The sl is not within range\n"); + sidput(slsid); + sidput(rangesid); + return 0; + } + plog(LLV_DEBUG, LOCATION, NULL, + "within_range: The sl (%s) is within range (%s)\n", sl, range); + return 1; +} From dwalsh at redhat.com Tue Sep 19 14:04:05 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 19 Sep 2006 10:04:05 -0400 Subject: [redhat-lspp] Re: MLS Policy (rawhide) In-Reply-To: <4501CD96.8020508@us.ibm.com> References: <4500906A.3000502@us.ibm.com> <4501B1B1.4020103@redhat.com> <4501C466.7060309@us.ibm.com> <1157744430.31695.210.camel@moss-spartans.epoch.ncsc.mil> <4501C8EA.7020105@us.ibm.com> <1157745813.31695.218.camel@moss-spartans.epoch.ncsc.mil> <4501CD96.8020508@us.ibm.com> Message-ID: <450FF8D5.7010004@redhat.com> Michael C Thompson wrote: > Stephen Smalley wrote: >> On Fri, 2006-09-08 at 14:47 -0500, Michael C Thompson wrote: >>> Stephen Smalley wrote: >>>> On Fri, 2006-09-08 at 14:28 -0500, Michael C Thompson wrote: >>>>> Daniel J Walsh wrote: >>>>>> Michael C Thompson wrote: >>>>>>> Hey all, >>>>>>> >>>>>>> It seems that ssh is unable to add entries to known_hosts for >>>>>>> the root user as sysadm_t. Is this a known issue? And if so, who >>>>>>> can add entries to /root/.ssh/known_hosts ? >>>>>>> >>>>>>> Thanks, >>>>>>> Mike >>>>>>> >>>>>> This works for me. How is the file labeled? >>>>> # ls -alZ /root/.ssh >>>>> drwx------ root root root:object_r:user_home_ssh_t:SystemLow . >>>>> drwxr-x--- root root >>>>> root:object_r:sysadm_home_dir_t:SystemLow-SystemHigh .. >>>>> -rw------- root root root:object_r:bin_t:SystemLow id_rsa >>>>> -rw-r--r-- root root root:object_r:bin_t:SystemLow id_rsa.pub >>>>> -rw-r--r-- root root root:object_r:user_home_ssh_t:SystemLow >>>>> known_hosts >>>> /sbin/restorecon -R /root/.ssh >>> I have relabeled this system numerous times with touch >>> /.autorelabel... why wasn't this picked up? >> >> Not sure, not a big fan of autorelabeling myself. > > Me either, not sure how it got some messed up though. > > > Is /home on a >> separate partition? Would it be mounted when the relabel runs from >> rc.sysinit? > > Well, it wasn't in /home, but even then that isn't the case. But it > works now, so thanks Stephen :) > > Mike > touch /.autorelabel should only be used when you have a serious labeling problem (file_t, selinux=0, changing policy types). This should seldom be done. I have not done it in over a year. The file system should not be getting badly mislabeled at this point. From dwalsh at redhat.com Tue Sep 19 14:10:43 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 19 Sep 2006 10:10:43 -0400 Subject: [redhat-lspp] SINGLEUSER Mode on crashed machines in initscripts Message-ID: <450FFA63.7020201@redhat.com> Add a line in /etc/sysconfig/autofsck AUTOFSCK_SINGLEUSER=1 Will turn it on. rpm -q initscripts initscripts-8.40-1 From latten at austin.ibm.com Tue Sep 19 19:11:20 2006 From: latten at austin.ibm.com (Joy Latten) Date: Tue, 19 Sep 2006 14:11:20 -0500 Subject: [redhat-lspp] question about racoon patch Message-ID: <200609191911.k8JJBKET012306@faith.austin.ibm.com> Venkat, I have been meaning to ask you about a part of the racoon patch. In file src/racoon/policy.c, routines, cmpspidxstrict() and cmpspidxwild(), there is the following code, #ifdef HAVE_SECCTX if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi #if 1 || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) #else || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, a->sec_ctx.ctx_strlen) != 0)) #endif return 1; #endif Since within_range() takes both contexts' sids (that of the proposal and that which is in the policy) and checks access, I assume we no longer want to ensure the security contexts match exactly. Only that one is permitted by the other, right? Are you ok with me removing the code after the "#else"? Or does the changes you will make soon, change this logic also and I should leave it alone for now? Just cleaning up the code and wondering about this. Thanks! Regards, Joy From latten at austin.ibm.com Tue Sep 19 21:17:20 2006 From: latten at austin.ibm.com (Joy Latten) Date: Tue, 19 Sep 2006 16:17:20 -0500 Subject: [redhat-lspp] ipsec acquire has security context although I am not using it. Message-ID: <200609192117.k8JLHKIC013043@faith.austin.ibm.com> When using ipsec while selinux is enabled in my kernel, my racoon daemon fails to establish an SA. I believe the ACQUIRE sent from kernel has a security context although I am not using this feature with ipsec. As a result, racoon fails to establish the SA, because it is looking for a policy with security context. I noticed the security context contains garbage. I am using a pseries, power5, ppc64 box, and it appears that since policy->security structure is not really initialized or zero'd out when not using, it is possible it may contain garbage on my pseries and a call such as "if (policy->security)" may come back as true such that security context is included in my acquire message although I believe it should not be. Hopefully, the below patch is acceptable. I have compiled and tested it. Regards, Joy Latten diff -urpN linux-2.6.17.orig/net/xfrm/xfrm_policy.c linux-2.6.17.patch/net/xfrm/xfrm_policy.c --- linux-2.6.17.orig/net/xfrm/xfrm_policy.c 2006-09-19 02:11:33.000000000 -0500 +++ linux-2.6.17.patch/net/xfrm/xfrm_policy.c 2006-09-19 04:33:50.000000000 -0500 @@ -319,6 +319,7 @@ struct xfrm_policy *xfrm_policy_alloc(gf init_timer(&policy->timer); policy->timer.data = (unsigned long)policy; policy->timer.function = xfrm_policy_timer; + policy->security = NULL; } return policy; } From vyekkirala at TrustedCS.com Tue Sep 19 21:49:59 2006 From: vyekkirala at TrustedCS.com (Venkat Yekkirala) Date: Tue, 19 Sep 2006 17:49:59 -0400 Subject: [redhat-lspp] RE: question about racoon patch Message-ID: <36282A1733C57546BE392885C0618592015730EC@chaos.tcs.tcs-sec.com> That was dead code. Please feel free to cleanup .Thanks. > -----Original Message----- > From: Joy Latten [mailto:latten at austin.ibm.com] > Sent: Tuesday, September 19, 2006 2:11 PM > To: vyekkirala at TrustedCs.com > Cc: redhat-lspp at redhat.com > Subject: question about racoon patch > > > Venkat, > > I have been meaning to ask you about a part of the racoon patch. > In file src/racoon/policy.c, routines, cmpspidxstrict() and > cmpspidxwild(), > there is the following code, > > #ifdef HAVE_SECCTX > if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg > || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi > #if 1 > || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) > #else > || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen > || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, > a->sec_ctx.ctx_strlen) != 0)) > #endif > return 1; > #endif > > Since within_range() takes both contexts' sids (that of the > proposal and > that which is in the policy) and checks access, > I assume we no longer want to ensure the security contexts match > exactly. Only that one is permitted by the other, right? > Are you ok with me removing the code after the "#else"? > Or does the changes you will make soon, change this logic also > and I should leave it alone for now? Just cleaning up the code > and wondering about this. > > Thanks! > > Regards, > Joy > From vyekkirala at TrustedCS.com Tue Sep 19 21:58:25 2006 From: vyekkirala at TrustedCS.com (Venkat Yekkirala) Date: Tue, 19 Sep 2006 17:58:25 -0400 Subject: [redhat-lspp] ipsec acquire has security context although I a m not using it. Message-ID: <36282A1733C57546BE392885C0618592015730EF@chaos.tcs.tcs-sec.com> This doesn't look right since kzalloc would already have zeroed the structure out. Are you sure you are getting garbage in the acquire from the kernel? If you are, I strongly doubt that this would be the one causing it (unless kzalloc on this arch misbehaved). Or is this a racoon bug? > -----Original Message----- > From: Joy Latten [mailto:latten at austin.ibm.com] > Sent: Tuesday, September 19, 2006 4:17 PM > To: netdev at vger.kernel.org; redhat-lspp at redhat.com; > selinux at tycho.nsa.gov > Cc: davem at davemloft.net; jmorris at namei.org > Subject: [redhat-lspp] ipsec acquire has security context > although I am > not using it. > > > > When using ipsec while selinux is enabled in my kernel, > my racoon daemon fails to establish an SA. I believe the > ACQUIRE sent from kernel has a security context although I > am not using this feature with ipsec. As a result, racoon > fails to establish the SA, because it is looking for a policy > with security context. I noticed the security context > contains garbage. > > I am using a pseries, power5, ppc64 box, and it appears > that since policy->security structure is not really initialized > or zero'd out when not using, it is possible it may contain garbage > on my pseries and a call such as "if (policy->security)" may > come back as true such that security context is included in > my acquire message although I believe it should not be. > > Hopefully, the below patch is acceptable. I have compiled and > tested it. > > Regards, > Joy Latten > > > diff -urpN linux-2.6.17.orig/net/xfrm/xfrm_policy.c > linux-2.6.17.patch/net/xfrm/xfrm_policy.c > --- linux-2.6.17.orig/net/xfrm/xfrm_policy.c 2006-09-19 > 02:11:33.000000000 -0500 > +++ linux-2.6.17.patch/net/xfrm/xfrm_policy.c 2006-09-19 > 04:33:50.000000000 -0500 > @@ -319,6 +319,7 @@ struct xfrm_policy *xfrm_policy_alloc(gf > init_timer(&policy->timer); > policy->timer.data = (unsigned long)policy; > policy->timer.function = xfrm_policy_timer; > + policy->security = NULL; > } > return policy; > } > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp > From latten at austin.ibm.com Wed Sep 20 15:16:43 2006 From: latten at austin.ibm.com (Joy Latten) Date: Wed, 20 Sep 2006 10:16:43 -0500 Subject: [redhat-lspp] ipsec acquire has security context although I a m not using it. Message-ID: <200609201516.k8KFGh1I018437@faith.austin.ibm.com> Venkat, >This doesn't look right since kzalloc would already have zeroed the >structure out. Are you sure you are getting garbage in the acquire >from the kernel? If you are, I strongly doubt that this would be the >one causing it (unless kzalloc on this arch misbehaved). >Or is this a racoon bug? Yes, you are correct! Thanks for pointing this out to me as I missed it! It is racoon that has the bug. Will fix and post correct fix shortly. Please ignore attached fix as it is incorrect. Again, thanks! Regards, Joy >> When using ipsec while selinux is enabled in my kernel, >> my racoon daemon fails to establish an SA. I believe the >> ACQUIRE sent from kernel has a security context although I >> am not using this feature with ipsec. As a result, racoon >> fails to establish the SA, because it is looking for a policy >> with security context. I noticed the security context >> contains garbage. >> >> I am using a pseries, power5, ppc64 box, and it appears >> that since policy->security structure is not really initialized >> or zero'd out when not using, it is possible it may contain garbage >> on my pseries and a call such as "if (policy->security)" may >> come back as true such that security context is included in >> my acquire message although I believe it should not be. >> >> Hopefully, the below patch is acceptable. I have compiled and >> tested it. >> >> Regards, >> Joy Latten >> >> >> diff -urpN linux-2.6.17.orig/net/xfrm/xfrm_policy.c >> linux-2.6.17.patch/net/xfrm/xfrm_policy.c >> --- linux-2.6.17.orig/net/xfrm/xfrm_policy.c 2006-09-19 >> 02:11:33.000000000 -0500 >> +++ linux-2.6.17.patch/net/xfrm/xfrm_policy.c 2006-09-19 >> 04:33:50.000000000 -0500 >> @@ -319,6 +319,7 @@ struct xfrm_policy *xfrm_policy_alloc(gf >> init_timer(&policy->timer); >> policy->timer.data = (unsigned long)policy; >> policy->timer.function = xfrm_policy_timer; >> + policy->security = NULL; >> } >> return policy; >> } >> -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo at tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message. From loulwas at us.ibm.com Wed Sep 20 15:40:03 2006 From: loulwas at us.ibm.com (Loulwa Salem) Date: Wed, 20 Sep 2006 10:40:03 -0500 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field Message-ID: <451160D3.705@us.ibm.com> Hi, Regarding the sample record below, is there a reason we got rid of the acct= field and now have two uid fields. I know the second uid field that is part of the message is referring to the uid of the user that logged in, but I think having the acct= (telling us the user name) was more useful... Also having two fields named the same within the same record is confusing for parsing. type=USER_LOGIN msg=audit(1158765381.613:26419): user pid=25321 uid=0 auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c255 msg='uid=500: exe="/usr/sbin/sshd" (hostname=mysystem.ibm.com, addr=2.0.0.0, terminal=/dev/pts/3 res=success)' To recreate this: - Tail the audit log file - In another window ssh to the system, and you'll see the above record among a few others. btw, other user related records that get generated (USER_START, USER_ACCT, USER_REFR) all have the acct= field. I am running with: # uname -a Linux system.ibm.com 2.6.17-1.2586.2.2.fc6.lspp.48 #1 SMP Wed Aug 30 15:51:12 EDT 2006 x86_64 x86_64 x86_64 GNU/Linux # rpm -q audit audit-1.2.6-3 Thanks, - Loulwa From sgrubb at redhat.com Wed Sep 20 16:14:01 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 20 Sep 2006 12:14:01 -0400 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <451160D3.705@us.ibm.com> References: <451160D3.705@us.ibm.com> Message-ID: <200609201214.01836.sgrubb@redhat.com> On Wednesday 20 September 2006 11:40, Loulwa Salem wrote: > Regarding the sample record below, is there a reason we got rid of the > acct= field and now have two uid fields. This is a "new" record type that wasn't part of CAPP. Its aim was to help clarify that a login occurred vs new session to aid NISPOM. So, acct was never in this message. The first uid field is what the kernel sees. In this case sshd is running as root, so that is correctly reported. > I know the second uid field that is part of the message is referring to the > uid of the user that logged in, but I think having the acct= (telling us the > user name) was more useful... Inside the msg is the information logged by sshd regarding who, what, when, where, and result. Uid is given because they have successfully identified themselves to the system and its shorter. Going from uid to acct name is easy and you never know when people change their name string causing lookup errors. In the case where we log a message pre-authentication, you get acct since it did not correlate to a uid. > Also having two fields named the same within the same record is confusing > for parsing. Yeah, not sure if we really want to do anything here. > type=USER_LOGIN msg=audit(1158765381.613:26419): user pid=25321 uid=0 > auid=4294967295 subj=system_u:system_r:sshd_t:s0-s15:c0.c255 msg='uid=500: > exe="/usr/sbin/sshd" (hostname=mysystem.ibm.com, addr=2.0.0.0, > terminal=/dev/pts/3 res=success)' -Steve From linda.knippers at hp.com Wed Sep 20 16:58:51 2006 From: linda.knippers at hp.com (Linda Knippers) Date: Wed, 20 Sep 2006 12:58:51 -0400 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <200609201214.01836.sgrubb@redhat.com> References: <451160D3.705@us.ibm.com> <200609201214.01836.sgrubb@redhat.com> Message-ID: <4511734B.2060005@hp.com> > Inside the msg is the information logged by sshd regarding who, what, when, > where, and result. Uid is given because they have successfully identified > themselves to the system and its shorter. Going from uid to acct name is easy > and you never know when people change their name string causing lookup > errors. > > In the case where we log a message pre-authentication, you get acct since it > did not correlate to a uid. I think it would be nice if the success message and the failure message had the same information, so acct in both cases if that's all we can get for the failure case. This is what we see now: type=USER_LOGIN msg=audit(1158674606.789:1503): user pid=10052 uid=0 auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 msg='uid=0: exe="/usr/sbin/sshd" (hostname=16.116.117.213, addr=2.0.0.0, terminal=/dev/pts/3 res=success)' type=USER_LOGIN msg=audit(1158668540.641:1460): user pid=9595 uid=0 auid=4294967295 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 msg='acct=root: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=sshd res=failed)' Do you know why we often get an addr of 2.0.0.0? Also, why does terminal=sshd in the failure case? And are we not able to get the hostname and other info in that case? -- ljk From linda.knippers at hp.com Wed Sep 20 17:20:03 2006 From: linda.knippers at hp.com (Linda Knippers) Date: Wed, 20 Sep 2006 13:20:03 -0400 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <4511734B.2060005@hp.com> References: <451160D3.705@us.ibm.com> <200609201214.01836.sgrubb@redhat.com> <4511734B.2060005@hp.com> Message-ID: <45117843.70801@hp.com> Linda Knippers wrote: >>Inside the msg is the information logged by sshd regarding who, what, when, >>where, and result. Uid is given because they have successfully identified >>themselves to the system and its shorter. Going from uid to acct name is easy >>and you never know when people change their name string causing lookup >>errors. >> >>In the case where we log a message pre-authentication, you get acct since it >>did not correlate to a uid. > > > I think it would be nice if the success message and the failure > message had the same information, so acct in both cases if that's > all we can get for the failure case. This is what we see now: > > type=USER_LOGIN msg=audit(1158674606.789:1503): user pid=10052 uid=0 > auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 msg='uid=0: > exe="/usr/sbin/sshd" (hostname=16.116.117.213, addr=2.0.0.0, > terminal=/dev/pts/3 res=success)' > > type=USER_LOGIN msg=audit(1158668540.641:1460): user pid=9595 uid=0 > auid=4294967295 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 > msg='acct=root: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=sshd > res=failed)' > > Do you know why we often get an addr of 2.0.0.0? Also, why does > terminal=sshd in the failure case? And are we not able to get > the hostname and other info in that case? I just upgraded from audit 1.2.5 to 1.2.7 and now I see slightly different information in the hostname/addr/terminal fields: type=USER_LOGIN msg=audit(1158758206.573:1685): user pid=24082 uid=0 auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 msg='uid=0: exe="/usr/sbin/sshd" (hostname=kipper.zko.hp.com, addr=2.0.0.0, terminal=/dev/pts/4 res=success)' type=USER_LOGIN msg=audit(1158758201.133:1677): user pid=24078 uid=0 auid=4294967295 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 msg='acct=root: exe="/usr/sbin/sshd" (hostname=?, addr=16.116.113.237, terminal=sshd res=failed)' The hostname is correct for the success case and the address is correct for the failure case. I suppose terminal isn't known on the failure case because the login didn't occur? In that case, should it be '?'? I see addr=2.0.0.0 on other messages too so my question about that isn't specific to this message type. -- ljk From sgrubb at redhat.com Wed Sep 20 18:37:20 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 20 Sep 2006 14:37:20 -0400 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <4511734B.2060005@hp.com> References: <451160D3.705@us.ibm.com> <200609201214.01836.sgrubb@redhat.com> <4511734B.2060005@hp.com> Message-ID: <200609201437.20166.sgrubb@redhat.com> On Wednesday 20 September 2006 12:58, Linda Knippers wrote: > > In the case where we log a message pre-authentication, you get acct since > > it did not correlate to a uid. > > I think it would be nice if the success message and the failure > message had the same information, so acct in both cases if that's > all we can get for the failure case. The audit system throughout has favored uids to names for compactness. Also users can change their name but rarely their uid. In all the trusted apps, the uid is more trustworthy since it has already been verified. > type=USER_LOGIN msg=audit(1158674606.789:1503): user pid=10052 uid=0 > auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 msg='uid=0: > exe="/usr/sbin/sshd" (hostname=16.116.117.213, addr=2.0.0.0, > terminal=/dev/pts/3 res=success)' > > type=USER_LOGIN msg=audit(1158668540.641:1460): user pid=9595 uid=0 > auid=4294967295 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 > msg='acct=root: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=sshd > res=failed)' > > Do you know why we often get an addr of 2.0.0.0? I'd have to trace through the code and know about your network. > Also, why does terminal=sshd in the failure case? I think the terminal isn't claimed until session open. > And are we not able to get the hostname and other info in that case? I'd have to look at the code. Patches are welcome... :) -Steve From linda.knippers at hp.com Wed Sep 20 18:40:37 2006 From: linda.knippers at hp.com (Linda Knippers) Date: Wed, 20 Sep 2006 14:40:37 -0400 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <200609201437.20166.sgrubb@redhat.com> References: <451160D3.705@us.ibm.com> <200609201214.01836.sgrubb@redhat.com> <4511734B.2060005@hp.com> <200609201437.20166.sgrubb@redhat.com> Message-ID: <45118B25.2090009@hp.com> Steve Grubb wrote: > On Wednesday 20 September 2006 12:58, Linda Knippers wrote: > >>>In the case where we log a message pre-authentication, you get acct since >>>it did not correlate to a uid. >> >>I think it would be nice if the success message and the failure >>message had the same information, so acct in both cases if that's >>all we can get for the failure case. > > > The audit system throughout has favored uids to names for compactness. Also > users can change their name but rarely their uid. In all the trusted apps, > the uid is more trustworthy since it has already been verified. > > >>type=USER_LOGIN msg=audit(1158674606.789:1503): user pid=10052 uid=0 >>auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 msg='uid=0: >>exe="/usr/sbin/sshd" (hostname=16.116.117.213, addr=2.0.0.0, >>terminal=/dev/pts/3 res=success)' >> >>type=USER_LOGIN msg=audit(1158668540.641:1460): user pid=9595 uid=0 >>auid=4294967295 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 >>msg='acct=root: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=sshd >>res=failed)' >> >>Do you know why we often get an addr of 2.0.0.0? > > > I'd have to trace through the code and know about your network. I don't think its related to our network. I noticed that Loulwa's example also had a 2.0.0.0 address. >>Also, why does terminal=sshd in the failure case? > > > I think the terminal isn't claimed until session open. > > >>And are we not able to get the hostname and other info in that case? > > > I'd have to look at the code. Patches are welcome... :) > > -Steve > > -- > redhat-lspp mailing list > redhat-lspp at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-lspp From loulwas at us.ibm.com Wed Sep 20 18:42:53 2006 From: loulwas at us.ibm.com (Loulwa Salem) Date: Wed, 20 Sep 2006 13:42:53 -0500 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <45118B25.2090009@hp.com> References: <451160D3.705@us.ibm.com> <200609201214.01836.sgrubb@redhat.com> <4511734B.2060005@hp.com> <200609201437.20166.sgrubb@redhat.com> <45118B25.2090009@hp.com> Message-ID: <45118BAD.2020603@us.ibm.com> Linda Knippers wrote: > Steve Grubb wrote: .... >> >>>type=USER_LOGIN msg=audit(1158674606.789:1503): user pid=10052 uid=0 >>>auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 msg='uid=0: >>>exe="/usr/sbin/sshd" (hostname=16.116.117.213, addr=2.0.0.0, >>>terminal=/dev/pts/3 res=success)' >>> >>>type=USER_LOGIN msg=audit(1158668540.641:1460): user pid=9595 uid=0 >>>auid=4294967295 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 >>>msg='acct=root: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=sshd >>>res=failed)' >>> >>>Do you know why we often get an addr of 2.0.0.0? >> >> >>I'd have to trace through the code and know about your network. > I don't know if this really has anything to do with a specific network because we get the same value as well. - Loulwa From sgrubb at redhat.com Wed Sep 20 18:46:19 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 20 Sep 2006 14:46:19 -0400 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <45117843.70801@hp.com> References: <451160D3.705@us.ibm.com> <4511734B.2060005@hp.com> <45117843.70801@hp.com> Message-ID: <200609201446.19761.sgrubb@redhat.com> On Wednesday 20 September 2006 13:20, Linda Knippers wrote: > I just upgraded from audit 1.2.5 to 1.2.7 and now I see slightly > different information in the hostname/addr/terminal fields: Well, the hostname/addr code changed. It was throwing away addr and using hostname. It was supposed to record what was given to it. > The hostname is correct for the success case and the address is > correct for the failure case. ?I suppose terminal isn't known on > the failure case because the login didn't occur? Right. Terminal is grabbed in session startup phase. > In that case, should it be '?'? The LOGIN event, I think, is using the pam data, so this is what was passed to pam. Traditionally, in the absence of a terminal, the daemon name was used. This predates the audit work. > I see addr=2.0.0.0 on other messages too so my question about that > isn't specific to this message type. If you find a problem in the code, please send a patch. Thanks, -Steve From sds at tycho.nsa.gov Wed Sep 20 20:26:37 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 20 Sep 2006 16:26:37 -0400 Subject: [redhat-lspp] Re: Problem with sshd and polyinstantiation In-Reply-To: References: Message-ID: <1158783997.15340.198.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-09-19 at 13:06 -0400, Rosalie Hiebel wrote: > I have noticed that when I have polyinstantiation with the instance > directory contained in the base directory, then sshd fails. It > appears that sshd goes through pam_namespace (which creates/mounts > instance directories), and then launches another sshd process which > also goes through pam_namespace. The second sshd fails to stat the > instance directory. > > So, if my namespace.conf contains the following entry, > /var/poly /var/poly/poly-inst context adm > then when I ssh in as root, two sshd processes output pam_namespace > messages to /var/log/secure. The first sshd successfully mounts the > instance directory, but the second sshd is unsuccessful (since it's > already mounted). The second sshd outputs the following error: > pam_namespace(sshd:session): Error stating /var/poly/poly-inst, No > such file or directory > pam_namespace(sshd:session): Error mounting > /var/poly/poly-inst/root on /var/poly, No such file or directory > > When I change the instance directory not to be a subdir of the base, > then sshd works fine. Is this a problem with sshd or is my setup > incorrect ? What happens if you put unmnt_remnt as an option after pam_namespace.so in your /etc/pam.d/sshd file? That is an option for programs like su and newrole that need to unmount and re-mount the instance directory, but may work in this situation (not sure). If that doesn't work either, then you might have to work around it by putting the instances outside of the base dir for now. -- Stephen Smalley National Security Agency From tmraz at redhat.com Wed Sep 20 20:43:54 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 20 Sep 2006 22:43:54 +0200 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <45118BAD.2020603@us.ibm.com> References: <451160D3.705@us.ibm.com> <200609201214.01836.sgrubb@redhat.com> <4511734B.2060005@hp.com> <200609201437.20166.sgrubb@redhat.com> <45118B25.2090009@hp.com> <45118BAD.2020603@us.ibm.com> Message-ID: <1158785034.6360.24.camel@perun.kabelta.loc> On Wed, 2006-09-20 at 13:42 -0500, Loulwa Salem wrote: > Linda Knippers wrote: > > Steve Grubb wrote: > .... > >> > >>>type=USER_LOGIN msg=audit(1158674606.789:1503): user pid=10052 uid=0 > >>>auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 msg='uid=0: > >>>exe="/usr/sbin/sshd" (hostname=16.116.117.213, addr=2.0.0.0, > >>>terminal=/dev/pts/3 res=success)' > >>> > >>>type=USER_LOGIN msg=audit(1158668540.641:1460): user pid=9595 uid=0 > >>>auid=4294967295 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 > >>>msg='acct=root: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=sshd > >>>res=failed)' > >>> > >>>Do you know why we often get an addr of 2.0.0.0? The code in audit library calls getaddrinfo() on the hostname, which is numeric. The getaddrinfo returns 2.0.0.0 address, I don't know why. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb From tmraz at redhat.com Wed Sep 20 21:11:20 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 20 Sep 2006 23:11:20 +0200 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <1158785034.6360.24.camel@perun.kabelta.loc> References: <451160D3.705@us.ibm.com> <200609201214.01836.sgrubb@redhat.com> <4511734B.2060005@hp.com> <200609201437.20166.sgrubb@redhat.com> <45118B25.2090009@hp.com> <45118BAD.2020603@us.ibm.com> <1158785034.6360.24.camel@perun.kabelta.loc> Message-ID: <1158786680.6360.29.camel@perun.kabelta.loc> On Wed, 2006-09-20 at 22:43 +0200, Tomas Mraz wrote: > On Wed, 2006-09-20 at 13:42 -0500, Loulwa Salem wrote: > > Linda Knippers wrote: > > > Steve Grubb wrote: > > .... > > >> > > >>>type=USER_LOGIN msg=audit(1158674606.789:1503): user pid=10052 uid=0 > > >>>auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 msg='uid=0: > > >>>exe="/usr/sbin/sshd" (hostname=16.116.117.213, addr=2.0.0.0, > > >>>terminal=/dev/pts/3 res=success)' > > >>> > > >>>type=USER_LOGIN msg=audit(1158668540.641:1460): user pid=9595 uid=0 > > >>>auid=4294967295 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 > > >>>msg='acct=root: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=sshd > > >>>res=failed)' > > >>> > > >>>Do you know why we often get an addr of 2.0.0.0? > The code in audit library calls getaddrinfo() on the hostname, which is > numeric. The getaddrinfo returns 2.0.0.0 address, I don't know why. Actually not true :-) It is a bug in the way inet_ntop is called. Here is a patch. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb -------------- next part -------------- A non-text attachment was scrubbed... Name: audit-1.2.7-gai.patch Type: text/x-patch Size: 512 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Sep 20 21:14:50 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 20 Sep 2006 17:14:50 -0400 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: Your message of "Wed, 20 Sep 2006 22:43:54 +0200." <1158785034.6360.24.camel@perun.kabelta.loc> References: <451160D3.705@us.ibm.com> <200609201214.01836.sgrubb@redhat.com> <4511734B.2060005@hp.com> <200609201437.20166.sgrubb@redhat.com> <45118B25.2090009@hp.com> <45118BAD.2020603@us.ibm.com> <1158785034.6360.24.camel@perun.kabelta.loc> Message-ID: <200609202114.k8KLEoIZ016906@turing-police.cc.vt.edu> On Wed, 20 Sep 2006 22:43:54 +0200, Tomas Mraz said: > On Wed, 2006-09-20 at 13:42 -0500, Loulwa Salem wrote: > > >>>Do you know why we often get an addr of 2.0.0.0? > The code in audit library calls getaddrinfo() on the hostname, which is > numeric. The getaddrinfo returns 2.0.0.0 address, I don't know why. Was that perchance an IPv6 address, and the code is coercing it to IPv4 and only reporting the first 4 bytes of it? I scared the begeebers out of myself once when my 'last login from' field had a hostname belonging to a DSL line in another timezone - took an hour for my heart rate to come down after I realized that the reported hostname was a PTR lookup of an IPv4 address that the bit pattern happened to be the first 4 bytes of my IPv6 address.. ;) (Not sure how you get a leading 2.0.0 out of that error though...) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From Valdis.Kletnieks at vt.edu Wed Sep 20 21:15:37 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 20 Sep 2006 17:15:37 -0400 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: Your message of "Wed, 20 Sep 2006 23:11:20 +0200." <1158786680.6360.29.camel@perun.kabelta.loc> References: <451160D3.705@us.ibm.com> <200609201214.01836.sgrubb@redhat.com> <4511734B.2060005@hp.com> <200609201437.20166.sgrubb@redhat.com> <45118B25.2090009@hp.com> <45118BAD.2020603@us.ibm.com> <1158785034.6360.24.camel@perun.kabelta.loc> <1158786680.6360.29.camel@perun.kabelta.loc> Message-ID: <200609202115.k8KLFbMU016939@turing-police.cc.vt.edu> On Wed, 20 Sep 2006 23:11:20 +0200, Tomas Mraz said: > Actually not true :-) > > It is a bug in the way inet_ntop is called. Here is a patch. Hmm... it appears I was totally correct. :) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available URL: From sgrubb at redhat.com Wed Sep 20 21:31:42 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 20 Sep 2006 17:31:42 -0400 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <1158786680.6360.29.camel@perun.kabelta.loc> References: <451160D3.705@us.ibm.com> <1158785034.6360.24.camel@perun.kabelta.loc> <1158786680.6360.29.camel@perun.kabelta.loc> Message-ID: <200609201731.42344.sgrubb@redhat.com> On Wednesday 20 September 2006 17:11, Tomas Mraz wrote: > It is a bug in the way inet_ntop is called. Here is a patch. Thanks, applied and will be in 1.2.8. -Steve From loulwas at us.ibm.com Thu Sep 21 15:22:35 2006 From: loulwas at us.ibm.com (Loulwa Salem) Date: Thu, 21 Sep 2006 10:22:35 -0500 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <4511734B.2060005@hp.com> References: <451160D3.705@us.ibm.com> <200609201214.01836.sgrubb@redhat.com> <4511734B.2060005@hp.com> Message-ID: <4512AE3B.3060806@us.ibm.com> Linda Knippers wrote: > type=USER_LOGIN msg=audit(1158674606.789:1503): user pid=10052 uid=0 > auid=0 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 msg='uid=0: > exe="/usr/sbin/sshd" (hostname=16.116.117.213, addr=2.0.0.0, > terminal=/dev/pts/3 res=success)' > > type=USER_LOGIN msg=audit(1158668540.641:1460): user pid=9595 uid=0 > auid=4294967295 subj=system_u:system_r:unconfined_t:s0-s0:c0.c255 > msg='acct=root: exe="/usr/sbin/sshd" (hostname=?, addr=?, terminal=sshd > res=failed)' > I need to parse this record type, so is this the final format of the record as far as we know? - Loulwa From sgrubb at redhat.com Thu Sep 21 15:31:04 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 21 Sep 2006 11:31:04 -0400 Subject: [redhat-lspp] USER_LOGIN record no longer has acct field In-Reply-To: <4512AE3B.3060806@us.ibm.com> References: <451160D3.705@us.ibm.com> <4511734B.2060005@hp.com> <4512AE3B.3060806@us.ibm.com> Message-ID: <200609211131.04788.sgrubb@redhat.com> On Thursday 21 September 2006 11:22, Loulwa Salem wrote: > I need to parse this record type, so is this the final format of the record > as far as we know? I think so. uid is more compact in the logs and not as susceptible to changing. -Steve From latten at austin.ibm.com Thu Sep 21 18:55:46 2006 From: latten at austin.ibm.com (Joy Latten) Date: Thu, 21 Sep 2006 13:55:46 -0500 Subject: [redhat-lspp] updated racoon patch Message-ID: <200609211855.k8LItkZw026669@faith.austin.ibm.com> This is the latest in a series of racoon patches. Upon testing racoon, it appeared racoon was still trying to lookup policy with a security context, although security contexts were not being used. This patch includes fix for this problem. Please replace any previous racoon patches, with this one. This patch is against ipsec-tools-0.6.5-3.1 in rawhide. Let me know if there are any problems. Regards, Joy Latten ---------------------------------------------------------------------------- diff -urpN ipsec-tools-0.6.5.orig/configure.ac ipsec-tools-0.6.5.0918/configure.ac --- ipsec-tools-0.6.5.orig/configure.ac 2006-08-22 00:49:52.000000000 -0500 +++ ipsec-tools-0.6.5.0918/configure.ac 2006-09-18 03:29:40.000000000 -0500 @@ -620,6 +620,7 @@ if test "$enable_security_context" = "ye AC_DEFINE([HAVE_SECCTX], [], [Enable Security Context]) SECCTX_OBJS="security.o" AC_SUBST(SECCTX_OBJS) + LIBS="$LIBS -lselinux" fi fi diff -urpN ipsec-tools-0.6.5.orig/src/racoon/cftoken.c ipsec-tools-0.6.5.0918/src/racoon/cftoken.c --- ipsec-tools-0.6.5.orig/src/racoon/cftoken.c 2006-08-22 00:49:52.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/cftoken.c 2006-09-18 02:57:23.000000000 -0500 @@ -1363,6 +1363,7 @@ char *yytext; #include "isakmp_var.h" #include "isakmp.h" #include "ipsec_doi.h" +#include "policy.h" #include "proposal.h" #include "nattraversal.h" #ifdef GC diff -urpN ipsec-tools-0.6.5.orig/src/racoon/isakmp_quick.c ipsec-tools-0.6.5.0918/src/racoon/isakmp_quick.c --- ipsec-tools-0.6.5.orig/src/racoon/isakmp_quick.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/isakmp_quick.c 2006-09-18 02:47:16.000000000 -0500 @@ -2128,5 +2128,11 @@ get_proposal_r(iph2) return ISAKMP_INTERNAL_ERROR; } +#ifdef HAVE_SECCTX + if (spidx.sec_ctx.ctx_str) { + set_secctx_in_proposal(iph2, spidx); + } +#endif /* HAVE_SECCTX */ + return 0; } diff -urpN ipsec-tools-0.6.5.orig/src/racoon/pfkey.c ipsec-tools-0.6.5.0918/src/racoon/pfkey.c --- ipsec-tools-0.6.5.orig/src/racoon/pfkey.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/pfkey.c 2006-09-21 01:35:43.000000000 -0500 @@ -1672,6 +1672,10 @@ pk_recvacquire(mhp) struct ph2handle *iph2[MAXNESTEDSA]; struct sockaddr *src, *dst; int n; /* # of phase 2 handler */ +#ifdef HAVE_SECCTX + struct sadb_x_sec_ctx *m_sec_ctx; +#endif /* HAVE_SECCTX */ + struct policyindex spidx; /* ignore this message because of local test mode. */ if (f_local) @@ -1691,6 +1695,24 @@ pk_recvacquire(mhp) src = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_SRC]); dst = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_DST]); +#ifdef HAVE_SECCTX + m_sec_ctx = (struct sadb_x_sec_ctx *)mhp[SADB_X_EXT_SEC_CTX]; + + if (m_sec_ctx != NULL) { + plog(LLV_INFO, LOCATION, NULL, + "security context doi: %u\n", + m_sec_ctx->sadb_x_ctx_doi); + plog(LLV_INFO, LOCATION, NULL, + "security context algorithm: %u\n", + m_sec_ctx->sadb_x_ctx_alg); + plog(LLV_INFO, LOCATION, NULL, + "security context length: %u\n", + m_sec_ctx->sadb_x_ctx_len); + plog(LLV_INFO, LOCATION, NULL, "security context: %s\n", + ((char *)m_sec_ctx + sizeof(struct sadb_x_sec_ctx))); + } +#endif /* HAVE_SECCTX */ + /* ignore if type is not IPSEC_POLICY_IPSEC */ if (xpl->sadb_x_policy_type != IPSEC_POLICY_IPSEC) { plog(LLV_DEBUG, LOCATION, NULL, @@ -1778,18 +1800,24 @@ pk_recvacquire(mhp) /* get inbound policy */ { - struct policyindex spidx; + memset(&spidx, 0, sizeof(spidx)); spidx.dir = IPSEC_DIR_INBOUND; memcpy(&spidx.src, &sp_out->spidx.dst, sizeof(spidx.src)); memcpy(&spidx.dst, &sp_out->spidx.src, sizeof(spidx.dst)); spidx.prefs = sp_out->spidx.prefd; spidx.prefd = sp_out->spidx.prefs; spidx.ul_proto = sp_out->spidx.ul_proto; + #ifdef HAVE_SECCTX - if (*sp_out->spidx.sec_ctx.ctx_str) - memcpy(&spidx.sec_ctx, &sp_out->spidx.sec_ctx, - sizeof(spidx.sec_ctx)); + if (m_sec_ctx) { + spidx.sec_ctx.ctx_doi = m_sec_ctx->sadb_x_ctx_doi; + spidx.sec_ctx.ctx_alg = m_sec_ctx->sadb_x_ctx_alg; + spidx.sec_ctx.ctx_strlen = m_sec_ctx->sadb_x_ctx_len; + memcpy(spidx.sec_ctx.ctx_str, + ((char *)m_sec_ctx + sizeof(struct sadb_x_sec_ctx)), + spidx.sec_ctx.ctx_strlen); + } #endif sp_in = getsp(&spidx); @@ -1877,6 +1905,12 @@ pk_recvacquire(mhp) delph2(iph2[n]); return -1; } +#ifdef HAVE_SECCTX + if (m_sec_ctx) { + set_secctx_in_proposal(iph2[n], spidx); + } +#endif /* HAVE_SECCTX */ + insph2(iph2[n]); /* start isakmp initiation by using ident exchange */ diff -urpN ipsec-tools-0.6.5.orig/src/racoon/policy.c ipsec-tools-0.6.5.0918/src/racoon/policy.c --- ipsec-tools-0.6.5.orig/src/racoon/policy.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/policy.c 2006-09-21 02:04:10.000000000 -0500 @@ -206,9 +206,7 @@ cmpspidxstrict(a, b) #ifdef HAVE_SECCTX if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi - || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen - || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, - a->sec_ctx.ctx_strlen) != 0)) + || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) return 1; #endif return 0; @@ -284,9 +282,7 @@ cmpspidxwild(a, b) #ifdef HAVE_SECCTX if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi - || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen - || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, - a->sec_ctx.ctx_strlen) != 0)) + || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) return 1; #endif diff -urpN ipsec-tools-0.6.5.orig/src/racoon/policy.h ipsec-tools-0.6.5.0918/src/racoon/policy.h --- ipsec-tools-0.6.5.orig/src/racoon/policy.h 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/policy.h 2006-09-18 03:05:08.000000000 -0500 @@ -35,6 +35,7 @@ #include #ifdef HAVE_SECCTX + #define MAX_CTXSTR_SIZE 50 struct security_ctx { u_int8_t ctx_doi; /* Security Context DOI */ @@ -146,6 +147,11 @@ extern void initsp __P((void)); extern struct ipsecrequest *newipsecreq __P((void)); extern const char *spidx2str __P((const struct policyindex *)); +#ifdef HAVE_SECCTX +#include extern int get_security_context __P((vchar_t *, struct policyindex *)); +extern int within_range __P((security_context_t, security_context_t)); +extern void set_secctx_in_proposal __P((struct ph2handle *, struct policyindex)); +#endif #endif /* _POLICY_H */ diff -urpN ipsec-tools-0.6.5.orig/src/racoon/proposal.c ipsec-tools-0.6.5.0918/src/racoon/proposal.c --- ipsec-tools-0.6.5.orig/src/racoon/proposal.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/proposal.c 2006-09-18 02:47:16.000000000 -0500 @@ -1025,15 +1025,6 @@ set_proposal_from_policy(iph2, sp_main, newpp->lifetime = iph2->sainfo->lifetime; newpp->lifebyte = iph2->sainfo->lifebyte; newpp->pfs_group = iph2->sainfo->pfs_group; -#ifdef HAVE_SECCTX - if (*sp_main->spidx.sec_ctx.ctx_str) { - newpp->sctx.ctx_doi = sp_main->spidx.sec_ctx.ctx_doi; - newpp->sctx.ctx_alg = sp_main->spidx.sec_ctx.ctx_alg; - newpp->sctx.ctx_strlen = sp_main->spidx.sec_ctx.ctx_strlen; - memcpy(newpp->sctx.ctx_str, sp_main->spidx.sec_ctx.ctx_str, - sp_main->spidx.sec_ctx.ctx_strlen); - } -#endif /* HAVE_SECCTX */ if (lcconf->complex_bundle) goto skip1; @@ -1196,7 +1187,11 @@ set_proposal_from_proposal(iph2) pp0->sctx.ctx_strlen = pp_peer->sctx.ctx_strlen; memcpy(pp0->sctx.ctx_str, pp_peer->sctx.ctx_str, pp_peer->sctx.ctx_strlen); + + plog(LLV_INFO, LOCATION, NULL, + "RESPONDING with (%s).\n", pp_peer->sctx.ctx_str); } + #endif /* HAVE_SECCTX */ if (pp_peer->next != NULL) { diff -urpN ipsec-tools-0.6.5.orig/src/racoon/security.c ipsec-tools-0.6.5.0918/src/racoon/security.c --- ipsec-tools-0.6.5.orig/src/racoon/security.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/security.c 2006-09-18 10:58:37.000000000 -0500 @@ -1,5 +1,6 @@ /* * Copyright (C) 2005 International Business Machines Corporation + * Copyright (c) 2005 by Trusted Computer Solutions, Inc. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -36,6 +37,12 @@ #include #include +#include +#include +#include +#include +#include + #include "var.h" #include "vmbuf.h" #include "misc.h" @@ -45,6 +52,7 @@ #include "isakmp.h" #include "ipsec_doi.h" #include "policy.h" +#include "proposal.h" #include "strnames.h" #include "handler.h" @@ -150,3 +158,112 @@ get_security_context(sa, p) } return 0; } + +void +set_secctx_in_proposal(iph2, spidx) + struct ph2handle *iph2; + struct policyindex spidx; +{ + iph2->proposal->sctx.ctx_doi = spidx.sec_ctx.ctx_doi; + iph2->proposal->sctx.ctx_alg = spidx.sec_ctx.ctx_alg; + iph2->proposal->sctx.ctx_strlen = spidx.sec_ctx.ctx_strlen; + memcpy(iph2->proposal->sctx.ctx_str, spidx.sec_ctx.ctx_str, + spidx.sec_ctx.ctx_strlen); +} + + +/* + * function: init_avc + * description: function performs the steps necessary to initialize the + * userspace avc. + * input: void + * return: 0 if avc was successfully initialized + * 1 if the avc could not be initialized + */ + +static int +init_avc(void) +{ + int rtn = 0; + + if (!is_selinux_mls_enabled()) { + plog(LLV_ERROR, LOCATION, NULL, "racoon: MLS support is not" + " enabled.\n"); + return 1; + } + + rtn = avc_init("racoon", NULL, NULL, NULL, NULL); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, "racoon: could not initialize avc.\n"); + rtn = 1; + } + return rtn; +} + +/* + * function: within_range + * description: function determines if the specified sl is within the + * configured range for a policy rule. + * input: security_context *sl SL + * char *range Range + * return: 1 if the sl is within the range + * 0 if the sl is not within the range or an error + * occurred which prevented the determination + */ + +int +within_range(security_context_t sl, security_context_t range) +{ + int rtn = 1; + security_id_t slsid; + security_id_t rangesid; + struct av_decision avd; + security_class_t tclass; + access_vector_t av; + + if (!*range) /* This policy doesn't have security context */ + return 1; + + rtn = init_avc(); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: couldn't initialize the AVC\n"); + return 0; + } + + /* + * Get the sids for the sl and range contexts + */ + rtn = avc_context_to_sid(sl, &slsid); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: Unable to retrieve " + "sid for sl context (%s).\n", sl); + return 0; + } + rtn = avc_context_to_sid(range, &rangesid); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: Unable to retrieve " + "sid for range context (%s).\n", range); + sidput(slsid); + return 0; + } + + /* + * Straight up test between sl and range + */ + tclass = SECCLASS_ASSOCIATION; + av = ASSOCIATION__POLMATCH; + rtn = avc_has_perm(slsid, rangesid, tclass, av, NULL, &avd); + if (rtn != 0) { + plog(LLV_INFO, LOCATION, NULL, + "within_range: The sl is not within range\n"); + sidput(slsid); + sidput(rangesid); + return 0; + } + plog(LLV_DEBUG, LOCATION, NULL, + "within_range: The sl (%s) is within range (%s)\n", sl, range); + return 1; +} From latten at austin.ibm.com Thu Sep 21 22:00:51 2006 From: latten at austin.ibm.com (Joy Latten) Date: Thu, 21 Sep 2006 17:00:51 -0500 Subject: [redhat-lspp] updated racoon patch Message-ID: <200609212200.k8LM0pgE027544@faith.austin.ibm.com> I forgot to add that I will stress test racoon & ipsec again tonight to verify all is working. This patch will need to be picked up and included into the ipsec-tools-0.6.5 package in rawhide to support racoon negotiating and including mls labels in SAs. Joy >This is the latest in a series of racoon patches. >Upon testing racoon, it appeared racoon was still trying >to lookup policy with a security context, although >security contexts were not being used. >This patch includes fix for this problem. > >Please replace any previous racoon patches, with this one. >This patch is against ipsec-tools-0.6.5-3.1 in rawhide. > >Let me know if there are any problems. > >Regards, >Joy Latten ---------------------------------------------------------------------------- diff -urpN ipsec-tools-0.6.5.orig/configure.ac ipsec-tools-0.6.5.0918/configure.ac --- ipsec-tools-0.6.5.orig/configure.ac 2006-08-22 00:49:52.000000000 -0500 +++ ipsec-tools-0.6.5.0918/configure.ac 2006-09-18 03:29:40.000000000 -0500 @@ -620,6 +620,7 @@ if test "$enable_security_context" = "ye AC_DEFINE([HAVE_SECCTX], [], [Enable Security Context]) SECCTX_OBJS="security.o" AC_SUBST(SECCTX_OBJS) + LIBS="$LIBS -lselinux" fi fi diff -urpN ipsec-tools-0.6.5.orig/src/racoon/cftoken.c ipsec-tools-0.6.5.0918/src/racoon/cftoken.c --- ipsec-tools-0.6.5.orig/src/racoon/cftoken.c 2006-08-22 00:49:52.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/cftoken.c 2006-09-18 02:57:23.000000000 -0500 @@ -1363,6 +1363,7 @@ char *yytext; #include "isakmp_var.h" #include "isakmp.h" #include "ipsec_doi.h" +#include "policy.h" #include "proposal.h" #include "nattraversal.h" #ifdef GC diff -urpN ipsec-tools-0.6.5.orig/src/racoon/isakmp_quick.c ipsec-tools-0.6.5.0918/src/racoon/isakmp_quick.c --- ipsec-tools-0.6.5.orig/src/racoon/isakmp_quick.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/isakmp_quick.c 2006-09-18 02:47:16.000000000 -0500 @@ -2128,5 +2128,11 @@ get_proposal_r(iph2) return ISAKMP_INTERNAL_ERROR; } +#ifdef HAVE_SECCTX + if (spidx.sec_ctx.ctx_str) { + set_secctx_in_proposal(iph2, spidx); + } +#endif /* HAVE_SECCTX */ + return 0; } diff -urpN ipsec-tools-0.6.5.orig/src/racoon/pfkey.c ipsec-tools-0.6.5.0918/src/racoon/pfkey.c --- ipsec-tools-0.6.5.orig/src/racoon/pfkey.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/pfkey.c 2006-09-21 01:35:43.000000000 -0500 @@ -1672,6 +1672,10 @@ pk_recvacquire(mhp) struct ph2handle *iph2[MAXNESTEDSA]; struct sockaddr *src, *dst; int n; /* # of phase 2 handler */ +#ifdef HAVE_SECCTX + struct sadb_x_sec_ctx *m_sec_ctx; +#endif /* HAVE_SECCTX */ + struct policyindex spidx; /* ignore this message because of local test mode. */ if (f_local) @@ -1691,6 +1695,24 @@ pk_recvacquire(mhp) src = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_SRC]); dst = PFKEY_ADDR_SADDR(mhp[SADB_EXT_ADDRESS_DST]); +#ifdef HAVE_SECCTX + m_sec_ctx = (struct sadb_x_sec_ctx *)mhp[SADB_X_EXT_SEC_CTX]; + + if (m_sec_ctx != NULL) { + plog(LLV_INFO, LOCATION, NULL, + "security context doi: %u\n", + m_sec_ctx->sadb_x_ctx_doi); + plog(LLV_INFO, LOCATION, NULL, + "security context algorithm: %u\n", + m_sec_ctx->sadb_x_ctx_alg); + plog(LLV_INFO, LOCATION, NULL, + "security context length: %u\n", + m_sec_ctx->sadb_x_ctx_len); + plog(LLV_INFO, LOCATION, NULL, "security context: %s\n", + ((char *)m_sec_ctx + sizeof(struct sadb_x_sec_ctx))); + } +#endif /* HAVE_SECCTX */ + /* ignore if type is not IPSEC_POLICY_IPSEC */ if (xpl->sadb_x_policy_type != IPSEC_POLICY_IPSEC) { plog(LLV_DEBUG, LOCATION, NULL, @@ -1778,18 +1800,24 @@ pk_recvacquire(mhp) /* get inbound policy */ { - struct policyindex spidx; + memset(&spidx, 0, sizeof(spidx)); spidx.dir = IPSEC_DIR_INBOUND; memcpy(&spidx.src, &sp_out->spidx.dst, sizeof(spidx.src)); memcpy(&spidx.dst, &sp_out->spidx.src, sizeof(spidx.dst)); spidx.prefs = sp_out->spidx.prefd; spidx.prefd = sp_out->spidx.prefs; spidx.ul_proto = sp_out->spidx.ul_proto; + #ifdef HAVE_SECCTX - if (*sp_out->spidx.sec_ctx.ctx_str) - memcpy(&spidx.sec_ctx, &sp_out->spidx.sec_ctx, - sizeof(spidx.sec_ctx)); + if (m_sec_ctx) { + spidx.sec_ctx.ctx_doi = m_sec_ctx->sadb_x_ctx_doi; + spidx.sec_ctx.ctx_alg = m_sec_ctx->sadb_x_ctx_alg; + spidx.sec_ctx.ctx_strlen = m_sec_ctx->sadb_x_ctx_len; + memcpy(spidx.sec_ctx.ctx_str, + ((char *)m_sec_ctx + sizeof(struct sadb_x_sec_ctx)), + spidx.sec_ctx.ctx_strlen); + } #endif sp_in = getsp(&spidx); @@ -1877,6 +1905,12 @@ pk_recvacquire(mhp) delph2(iph2[n]); return -1; } +#ifdef HAVE_SECCTX + if (m_sec_ctx) { + set_secctx_in_proposal(iph2[n], spidx); + } +#endif /* HAVE_SECCTX */ + insph2(iph2[n]); /* start isakmp initiation by using ident exchange */ diff -urpN ipsec-tools-0.6.5.orig/src/racoon/policy.c ipsec-tools-0.6.5.0918/src/racoon/policy.c --- ipsec-tools-0.6.5.orig/src/racoon/policy.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/policy.c 2006-09-21 02:04:10.000000000 -0500 @@ -206,9 +206,7 @@ cmpspidxstrict(a, b) #ifdef HAVE_SECCTX if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi - || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen - || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, - a->sec_ctx.ctx_strlen) != 0)) + || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) return 1; #endif return 0; @@ -284,9 +282,7 @@ cmpspidxwild(a, b) #ifdef HAVE_SECCTX if (a->sec_ctx.ctx_alg != b->sec_ctx.ctx_alg || a->sec_ctx.ctx_doi != b->sec_ctx.ctx_doi - || a->sec_ctx.ctx_strlen != b->sec_ctx.ctx_strlen - || (memcmp(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str, - a->sec_ctx.ctx_strlen) != 0)) + || !within_range(a->sec_ctx.ctx_str, b->sec_ctx.ctx_str)) return 1; #endif diff -urpN ipsec-tools-0.6.5.orig/src/racoon/policy.h ipsec-tools-0.6.5.0918/src/racoon/policy.h --- ipsec-tools-0.6.5.orig/src/racoon/policy.h 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/policy.h 2006-09-18 03:05:08.000000000 -0500 @@ -35,6 +35,7 @@ #include #ifdef HAVE_SECCTX + #define MAX_CTXSTR_SIZE 50 struct security_ctx { u_int8_t ctx_doi; /* Security Context DOI */ @@ -146,6 +147,11 @@ extern void initsp __P((void)); extern struct ipsecrequest *newipsecreq __P((void)); extern const char *spidx2str __P((const struct policyindex *)); +#ifdef HAVE_SECCTX +#include extern int get_security_context __P((vchar_t *, struct policyindex *)); +extern int within_range __P((security_context_t, security_context_t)); +extern void set_secctx_in_proposal __P((struct ph2handle *, struct policyindex)); +#endif #endif /* _POLICY_H */ diff -urpN ipsec-tools-0.6.5.orig/src/racoon/proposal.c ipsec-tools-0.6.5.0918/src/racoon/proposal.c --- ipsec-tools-0.6.5.orig/src/racoon/proposal.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/proposal.c 2006-09-18 02:47:16.000000000 -0500 @@ -1025,15 +1025,6 @@ set_proposal_from_policy(iph2, sp_main, newpp->lifetime = iph2->sainfo->lifetime; newpp->lifebyte = iph2->sainfo->lifebyte; newpp->pfs_group = iph2->sainfo->pfs_group; -#ifdef HAVE_SECCTX - if (*sp_main->spidx.sec_ctx.ctx_str) { - newpp->sctx.ctx_doi = sp_main->spidx.sec_ctx.ctx_doi; - newpp->sctx.ctx_alg = sp_main->spidx.sec_ctx.ctx_alg; - newpp->sctx.ctx_strlen = sp_main->spidx.sec_ctx.ctx_strlen; - memcpy(newpp->sctx.ctx_str, sp_main->spidx.sec_ctx.ctx_str, - sp_main->spidx.sec_ctx.ctx_strlen); - } -#endif /* HAVE_SECCTX */ if (lcconf->complex_bundle) goto skip1; @@ -1196,7 +1187,11 @@ set_proposal_from_proposal(iph2) pp0->sctx.ctx_strlen = pp_peer->sctx.ctx_strlen; memcpy(pp0->sctx.ctx_str, pp_peer->sctx.ctx_str, pp_peer->sctx.ctx_strlen); + + plog(LLV_INFO, LOCATION, NULL, + "RESPONDING with (%s).\n", pp_peer->sctx.ctx_str); } + #endif /* HAVE_SECCTX */ if (pp_peer->next != NULL) { diff -urpN ipsec-tools-0.6.5.orig/src/racoon/security.c ipsec-tools-0.6.5.0918/src/racoon/security.c --- ipsec-tools-0.6.5.orig/src/racoon/security.c 2006-08-22 00:49:53.000000000 -0500 +++ ipsec-tools-0.6.5.0918/src/racoon/security.c 2006-09-18 10:58:37.000000000 -0500 @@ -1,5 +1,6 @@ /* * Copyright (C) 2005 International Business Machines Corporation + * Copyright (c) 2005 by Trusted Computer Solutions, Inc. * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -36,6 +37,12 @@ #include #include +#include +#include +#include +#include +#include + #include "var.h" #include "vmbuf.h" #include "misc.h" @@ -45,6 +52,7 @@ #include "isakmp.h" #include "ipsec_doi.h" #include "policy.h" +#include "proposal.h" #include "strnames.h" #include "handler.h" @@ -150,3 +158,112 @@ get_security_context(sa, p) } return 0; } + +void +set_secctx_in_proposal(iph2, spidx) + struct ph2handle *iph2; + struct policyindex spidx; +{ + iph2->proposal->sctx.ctx_doi = spidx.sec_ctx.ctx_doi; + iph2->proposal->sctx.ctx_alg = spidx.sec_ctx.ctx_alg; + iph2->proposal->sctx.ctx_strlen = spidx.sec_ctx.ctx_strlen; + memcpy(iph2->proposal->sctx.ctx_str, spidx.sec_ctx.ctx_str, + spidx.sec_ctx.ctx_strlen); +} + + +/* + * function: init_avc + * description: function performs the steps necessary to initialize the + * userspace avc. + * input: void + * return: 0 if avc was successfully initialized + * 1 if the avc could not be initialized + */ + +static int +init_avc(void) +{ + int rtn = 0; + + if (!is_selinux_mls_enabled()) { + plog(LLV_ERROR, LOCATION, NULL, "racoon: MLS support is not" + " enabled.\n"); + return 1; + } + + rtn = avc_init("racoon", NULL, NULL, NULL, NULL); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, "racoon: could not initialize avc.\n"); + rtn = 1; + } + return rtn; +} + +/* + * function: within_range + * description: function determines if the specified sl is within the + * configured range for a policy rule. + * input: security_context *sl SL + * char *range Range + * return: 1 if the sl is within the range + * 0 if the sl is not within the range or an error + * occurred which prevented the determination + */ + +int +within_range(security_context_t sl, security_context_t range) +{ + int rtn = 1; + security_id_t slsid; + security_id_t rangesid; + struct av_decision avd; + security_class_t tclass; + access_vector_t av; + + if (!*range) /* This policy doesn't have security context */ + return 1; + + rtn = init_avc(); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: couldn't initialize the AVC\n"); + return 0; + } + + /* + * Get the sids for the sl and range contexts + */ + rtn = avc_context_to_sid(sl, &slsid); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: Unable to retrieve " + "sid for sl context (%s).\n", sl); + return 0; + } + rtn = avc_context_to_sid(range, &rangesid); + if (rtn != 0) { + plog(LLV_ERROR, LOCATION, NULL, + "within_range: Unable to retrieve " + "sid for range context (%s).\n", range); + sidput(slsid); + return 0; + } + + /* + * Straight up test between sl and range + */ + tclass = SECCLASS_ASSOCIATION; + av = ASSOCIATION__POLMATCH; + rtn = avc_has_perm(slsid, rangesid, tclass, av, NULL, &avd); + if (rtn != 0) { + plog(LLV_INFO, LOCATION, NULL, + "within_range: The sl is not within range\n"); + sidput(slsid); + sidput(rangesid); + return 0; + } + plog(LLV_DEBUG, LOCATION, NULL, + "within_range: The sl (%s) is within range (%s)\n", sl, range); + return 1; +} -- redhat-lspp mailing list redhat-lspp at redhat.com https://www.redhat.com/mailman/listinfo/redhat-lspp From latten at austin.ibm.com Sat Sep 23 14:52:22 2006 From: latten at austin.ibm.com (Joy Latten) Date: Sat, 23 Sep 2006 09:52:22 -0500 Subject: [redhat-lspp] FYI: labeled ipsec w/ racoon test results Message-ID: <200609231452.k8NEqMwb007805@faith.austin.ibm.com> A stress test sending continuous streams of tcp and udp packets over a labeled ipsec connection, using racoon with latest patch, completed a successful 17-hour run. This test's purpose was to ensure no regression. Configuration: -2 pseries power5 machines -ipsec in transport mode, ipsec policy contained following security context, system_u:object_r:unlabeled_t:s0:c0 esp protocol with authentication enabled - kernel, 2.6.17-1.2617.2.1.fc6, from rawhide - mls policy, permissive mode - role, sysadm_r Regards, Joy Latten From ltcgcw at us.ibm.com Sat Sep 23 19:20:05 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Sat, 23 Sep 2006 14:20:05 -0500 Subject: [redhat-lspp] [Reminder] Open LSPP Development Telecon Mon., Sept. 25 Message-ID: <20060923192004.GA18743@us.ibm.com> IBM hosts a telecon every Monday at 20:00 UTC to discuss the development issues surrounding Linux LSPP certification. The call is open to all who have something to bring to the effort. If you would like to participate and are not already an attendee, please reply directly to me with your contact information. I will respond with an invitation. Please note that the number of attendees may be limited by our call center's restrictions on maximum lines per conference. -- George Wilson IBM Linux Technology Center From sgrubb at redhat.com Sun Sep 24 21:45:12 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Sun, 24 Sep 2006 17:45:12 -0400 Subject: [redhat-lspp] lspp 49 kernel released Message-ID: <200609241745.12984.sgrubb@redhat.com> Hi, The lspp.49 kernel has been published to the lspp yum repo at: http://people.redhat.com/sgrubb/files/lspp The changes are: - PPC fixup for success value in syscall audit records - Apply patch for unbounded name_count - 2.6.18 based kernel Please let me know if there any problems with this kernel. -Steve From sgrubb at redhat.com Mon Sep 25 12:43:09 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 25 Sep 2006 08:43:09 -0400 Subject: [redhat-lspp] updated racoon patch In-Reply-To: <200609211855.k8LItkZw026669@faith.austin.ibm.com> References: <200609211855.k8LItkZw026669@faith.austin.ibm.com> Message-ID: <200609250843.09248.sgrubb@redhat.com> On Thursday 21 September 2006 14:55, Joy Latten wrote: > +???????/* > +??????? * Straight up test between sl and range > +??????? */ > +???????tclass = SECCLASS_ASSOCIATION; > +???????av = ASSOCIATION__POLMATCH; This doesn't build. Where does the POLMATCH define come from? I can't find it anywhere. -Steve From sgrubb at redhat.com Mon Sep 25 13:47:52 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Mon, 25 Sep 2006 09:47:52 -0400 Subject: [redhat-lspp] updated racoon patch In-Reply-To: <200609250843.09248.sgrubb@redhat.com> References: <200609211855.k8LItkZw026669@faith.austin.ibm.com> <200609250843.09248.sgrubb@redhat.com> Message-ID: <200609250947.52327.sgrubb@redhat.com> On Monday 25 September 2006 08:43, Steve Grubb wrote: > This doesn't build. Where does the POLMATCH define come from? I can't find > it anywhere. Found that libselinux-devel and 2.6.18 kernel are not in sync. Please apply this patch: diff -ur libselinux-1.30.28.orig/include/selinux/av_permissions.h libselinux-1.30.28/include/selinux/av_permissions.h --- libselinux-1.30.28.orig/include/selinux/av_permissions.h 2006-09-25 09:44:13.000000000 -0400 +++ libselinux-1.30.28/include/selinux/av_permissions.h 2006-09-25 09:44:47.000000000 -0400 @@ -468,6 +468,7 @@ #define PROCESS__EXECSTACK 0x04000000UL #define PROCESS__EXECHEAP 0x08000000UL #define PROCESS__SETKEYCREATE 0x10000000UL +#define PROCESS__SETSOCKCREATE 0x20000000UL #define IPC__CREATE 0x00000001UL #define IPC__DESTROY 0x00000002UL @@ -910,6 +911,7 @@ #define ASSOCIATION__SENDTO 0x00000001UL #define ASSOCIATION__RECVFROM 0x00000002UL #define ASSOCIATION__SETCONTEXT 0x00000004UL +#define ASSOCIATION__POLMATCH 0x00000008UL #define NETLINK_KOBJECT_UEVENT_SOCKET__IOCTL 0x00000001UL #define NETLINK_KOBJECT_UEVENT_SOCKET__READ 0x00000002UL From dwalsh at redhat.com Mon Sep 25 15:23:54 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 25 Sep 2006 11:23:54 -0400 Subject: [redhat-lspp] [Fwd: How should we handle polmatch avcs?] Message-ID: <4517F48A.80506@redhat.com> Seems like we have a problem with current OpenSwan/IPSec stuff. I believe that some of these are bugs in the implementation. -------- Original Message -------- Subject: How should we handle polmatch avcs? Date: Sat, 23 Sep 2006 06:59:30 -0400 From: Daniel J Walsh To: Stephen Smalley , "Christopher J. PeBenito" https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207304 allow initrc_t self:association polmatch; allow unlabeled_t initrc_t:association polmatch; allow unlabeled_t self:association polmatch; From latten at austin.ibm.com Mon Sep 25 18:52:39 2006 From: latten at austin.ibm.com (Joy Latten) Date: Mon, 25 Sep 2006 13:52:39 -0500 Subject: [redhat-lspp] Re: [Fwd: How should we handle polmatch avcs?] Message-ID: <200609251852.k8PIqd5w031210@faith.austin.ibm.com> >Seems like we have a problem with current OpenSwan/IPSec stuff. > >I believe that some of these are bugs in the implementation. > >-------- Original Message -------- >Subject: How should we handle polmatch avcs? >Date: Sat, 23 Sep 2006 06:59:30 -0400 >From: Daniel J Walsh >To: Stephen Smalley , "Christopher J. PeBenito" > > > > >https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=207304 > >allow initrc_t self:association polmatch; >allow unlabeled_t initrc_t:association polmatch; >allow unlabeled_t self:association polmatch; I have run across the last of the 3 rules, and believe we do need it. The first 2, I have not come across yet. The last rule will definitely be needed by selinux_xfrm_state_pol_flow_match() when sending unlabeled packets. Because, avc_has_perm() takes SA sid and policy sid to check. And when sending unlabeled packets, these will both be unlabeled_t. I am not very familiar with openswan or pluto. My guess is they do not contain modifications to use labeled ipsec. Thus this is running just plain non-labeled ipsec. The first two rules, I am not sure I understand where they are being required. Could not be the hook mentioned above, because in the case of unlabeled packets, policy and SA sids will always be unlabeled_t. The only other hook that uses polmatch is selinux_xfrm_policy_lookup() and avc_has_perm() checks flow sid and policy sid. Again, in the case of unlabeled packets, the policy sid should always be unlabeled_t. So, target will always be unlabeled_t... maybe some sort of transition happens? I added "polmatch" to kernel_sendrecv_unlabeled_association interface in kernel.if. Originally, the check in selinux_xfrm_policy_lookup() was for association:sendto recvfrom. This was changed with the introduction of the latest set of patches to labeled ipsec that introduced, polmatch. Thus I figured we needed to add "polmatch" here too. Also, selinux_xfrm_policy_lookup() will get called when an app wants to send a packet. It does an avc_has_perm() using flow sid as source and policy sid as target. I noticed that the flow_sid must sometimes be assigned the socket sid, because for a ping, my source sid aka flow_sid is ping_t. avc_has_perm() appears to check if ping_t can access unlabeled_t. Thus, apps sending unlabeled ipsec packets, will call selinux_xfrm_policy_lookup... so it seem easier to just add polmatch in this interface. This interface gets called by corenet_non_ipsec_sendrecv in corenetwork.if. I noticed most apps/daemons and init call corenet_non_ipsec_sendrecv. Joy From jbrindle at tresys.com Mon Sep 25 16:07:00 2006 From: jbrindle at tresys.com (Joshua Brindle) Date: Mon, 25 Sep 2006 12:07:00 -0400 Subject: [redhat-lspp] Re: racoon patch In-Reply-To: <200609182302.k8IN2Zfu006200@faith.austin.ibm.com> References: <200609182302.k8IN2Zfu006200@faith.austin.ibm.com> Message-ID: <1159200420.3169.33.camel@twoface.columbia.tresys.com> On Mon, 2006-09-18 at 19:02 -0400, Joy Latten wrote: > The following adds Venkat's changes to racoon to understand > mls label. > > I have not yet thoroughly tested this patch. I have played with > it a little and have found that racoon won't establish an SA > when using ipsec without labels. The function, within_range() > appears to always assume there is a label. I am currently working > on fixing this. > > If you have any problems with this patch, please let me know. > > Basic steps to use: This seems to work well. I set up spd entries on 1 side with passwd_t and that context was propagated to the other side with the sources MLS range. However, on the initiator side the SA's are also passwd_t so there is no way for the client to verify the context of the server. Also, it seems that while the initiator domain's mls range is propagated to the remote SA but if I change mls range (from s0 to s0:c1.c255) it uses the same SA (which the reciever will think is coming from an s0 domain).. This seems counter-intuitive. I'm trying to set up rules and spd entries to do what we were talking about before, multiple spd entries that are polmatched by different domains in order to get some functionality of domain context transfer but I'm running in to strange things like unconfined_t trying to polmatch on unconfined_t even though there are no spd rules with unconfined_t, is this expected? From latten at austin.ibm.com Mon Sep 25 22:05:41 2006 From: latten at austin.ibm.com (Joy Latten) Date: Mon, 25 Sep 2006 17:05:41 -0500 Subject: [redhat-lspp] Re: racoon patch Message-ID: <200609252205.k8PM5fUV032263@faith.austin.ibm.com> >On Mon, 2006-09-18 at 19:02 -0400, Joy Latten wrote: >> The following adds Venkat's changes to racoon to understand >> mls label. >> >> I have not yet thoroughly tested this patch. I have played with >> it a little and have found that racoon won't establish an SA >> when using ipsec without labels. The function, within_range() >> appears to always assume there is a label. I am currently working >> on fixing this. >> >> If you have any problems with this patch, please let me know. >> >> Basic steps to use: > >This seems to work well. I set up spd entries on 1 side with passwd_t >and that context was propagated to the other side with the sources MLS >range. > >However, on the initiator side the SA's are also passwd_t so there is no >way for the client to verify the context of the server. Also, it seems >that while the initiator domain's mls range is propagated to the remote >SA but if I change mls range (from s0 to s0:c1.c255) it uses the same SA >(which the reciever will think is coming from an s0 domain).. This seems >counter-intuitive. I tried this using s0, s0:c0 and s0:c1.c255 in my policy. And no matter what, my SAs were always created with s0-s15:c0.c255. This is not correct to me. Let me investigate code and see what is up. > >I'm trying to set up rules and spd entries to do what we were talking >about before, multiple spd entries that are polmatched by different >domains in order to get some functionality of domain context transfer >but I'm running in to strange things like unconfined_t trying to >polmatch on unconfined_t even though there are no spd rules with >unconfined_t, is this expected? This is just as confusing as the earlier note with initrc_t trying to polmatch on initrc_t and using non-labeled ipsec. Something seems incorrect. I am not sure where this is coming from. I checked the code and could not find anywhere this should happen. In each access check for polmatch, target is security context in policy. What version of the kernel are you running? Regards, Joy From ltcgcw at us.ibm.com Tue Sep 26 00:44:45 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Mon, 25 Sep 2006 19:44:45 -0500 Subject: [redhat-lspp] Labeled networking telecon Message-ID: <20060926004445.GA19051@us.ibm.com> Today the LSPP telecon participants suggested that we have a separate meeting to discuss labeled networking. We would have to hold it soon because the RHEL5 cutoff date is approaching. IBM is willing to host using the same number as the LSPP call. How about 1 PM CDT tomorrow, Tuesday, Sept. 26? I think we need at least the core labeled networking experts from HP, IBM, NSA, Red Hat, Tresys, and TCS. Please respond to me if you are willing to participate. Be sure to include issues you want to see on the agenda. If 1 PM CDT tomorrow is bad for you, please send a counterproposal. I will send out a notice at roughly 11 AM CDT if we can get what looks like a quorum. If not, I will suggest a new time based on the responses. -- George Wilson IBM Linux Technology Center From loulwas at us.ibm.com Tue Sep 26 15:49:53 2006 From: loulwas at us.ibm.com (Loulwa Salem) Date: Tue, 26 Sep 2006 10:49:53 -0500 Subject: [redhat-lspp] LSPP Development Telecon 09/25/2006 Minutes Message-ID: <45194C21.6090105@us.ibm.com> 09/25/2006 lspp Meeting Minutes: =============================== Attendees George Wilson (IBM) - GW Loulwa Salem (IBM) - LS Michael Thompson (IBM) - MT Joy Latten (IBM) - JL Thiago Bauermann (IBM) - TB Irina Boverman (Red Hat) - IB Steve Grubb (Red Hat) - SG Dan Walsh (Red Hat) - DW Lisa Smith (HP) - LMS Linda Knippers (HP) - LK Matt Anderson (HP) - MA Paul Moore (HP) - PM Klaus Weidner (Atsec) - KW Darrel Goeddel (TCS) - DG Chad Hanson (TCS) - CH Venkat Yekkirala (TCS) - VY Josh Fisher () - JF Tentative Agenda: SG: Got email from Al and he might not be able to join us today. GW: Joy is joining soon, let me IM her. We'll be talking about networking and will be great to get her input on that. SG: do you think the right people will be on the phone today to discuss networking? GW: good question, do we need people like Stephen Smalley, James Morris on the call SG: or Eric Paris. I suggest we schedule a call with those people to discuss networking soon. PM: It may be better to have the teleconference next week so those that are working on code can get it in before code freeze. SG: I know you got your hands full, but what about the other guys who are waiting on the networking decisions PM: if I am the only one busy, then that's fine, I just got the impressions that there are others who are in a time crunch now as well DG: I would rather get it done early, so we can get a resolution and get the code in. PM: I think it needs to be in by end of this week. LK: I think it is worth having a conference call soon. With networking, if you don't pursue it, then it doesn't stand a chance. DG: I am selfish on that too, cause I don't like to maintain a kernel with specific code, so I want to see this in the upstream kernel as well. GW: should I set up a meeting for tomorrow afternoon SG: we need to poll people's availability first I think GW: ok, I'll send a note to the list GW: NSA list? GW: yes, and RH lspp list and send out an invite to those that respond. I'll shoot for tomorrow afternoon. I think we need to get this to closure, and discuss the bigger picture. I hope we can discuss some of that today as well. Kernel / Rawhide update ------------------------ GW: any kernel issues? SG: I rolled out lspp.49 kernel yesterday. it has fixes for ppc issue. LK: is that the ppid problem SG: no, that's separate and it needs trouble shooting. Right now ppid is the only bug we need to still look at GW: I'll load that kernel on a machine and give it a shot on ppc SELinux base update ------------------- GW: Dan, any selinux updates you have for us? DW: the cron problem seems to have gone away GW: fixed itself DW: James seemed to have fixed it on MLS. I also put a lot of fixes in over the weekend. Mike sent me some fixes that will go out tonight in mls policy. The autofschk problem is fixed (basically when the machine crashes) MA: Dan did you see the problem with the permission denied using the init scripts on MLS enforcing (version 2.3.14)? DW: you sent me an email? I think we talked about it on IRC. LK: Now that you have the AVC message, maybe you can send it to him. DW: send me what init you get that on, and I'll look at it MA: I see it on all. I am not convinced it is just my system, but didn't hear back from anyone if they've seen it. LK: I am not seeing it but I am running an older policy version and scared to update. DW: works for me. Send me what you have and I'll look into it. MLS policy issues ----------------- GW: we kinda talked about that, is there anything else to bring up? DW: Mike brought this up last week, where user add does a service in the background, there is a discussion now about how to handle this better. This is the same problem that happens with rpm, when you run rpm it runs under sysadm_r, we want to come up with a solution so you don't have to run run-init to get rpm to work. So upstream is looking into that now. KW: one policy issue. We had an idea about how tcp sessions are handled, tcp is setup only if you can get the fd. Currently you can establish a session then check if you can read/write to it; that causes calls to large number of syscalls. GW: and we don't want read/write to become security relevant, because then we need to audit them. Al talked about it before as performance impact also. KW: what is the reason that current policy does not insist on equal MLS labels to set up TCP connections GW: Klaus this might be one to take to the list. Joy do you have any thoughts about that. KW: I tried this with CIPSO, but not with IPsec, I think they would be the same PM: I think netlabel uses it's own object class and permission so it's separate from others and therefore should be easy to do the check. so What happened to the xinetd work that we were doing a while ago? KW: well, according to requirements, it's fine if trusted applications get MLS override (like mlsfileread/mlsfilewrite) capabilities so that it can use what TCP connections it wants. only for untrusted users we need to \ check the MLS labels. GW: who will make that change to the policy, Paul you want to experiment with that. PM: sure, but I am not thinking much about policy, I have lots of deadlines now. klaus and I have been working on net label policy. I'll look into that more once the kernel work is done. I can't look at it now, but I can answer some question if anyone else wants to try it. KW: I can look into that by end of this week. I can do that for CIPSO, but I don't have an IPsec setup working. GW: one thing we ran across also is the role hierarchy using dominance operator is not working as expected. we think that when a role dominates another then it is a union of all the roles it dominates. but you actually have to newrole to get the permissions associated with the roles. KW: I would rephrase, you have permission to enter types of other roles, but type associated with role is what you log in with. You still manually have to transition into the other type. You need to manually add all the allow rules to that type. You always have to transition so it's not helpful if you want to use it to simplify work GW: I guess the question "is that the way everyone expects hierarchical roles to work with the dominance operator?" DW: Stephen Smalley put out a note explaining this a while ago KW: It would be good to add this in future that when you use dominance operator you get the rules for the roles added as well. DW: if we had a tool, it'll be a matter of running a loadable module on the fly to allow the transition GW: sounds scary at this point DW: yes, but it is something we are looking into. we are at RH looking into policy generation tool KW: RBAC has requirements for hierarchical roles, so currently we can claim to fulfill that, it is just a bit ugly. GW: ok, that's good Print ----- GW: any updates for print Matt? MA: I got sucked into alot of policy problems that delayed my release last week. I talked to Linda and we came up with better solution to verify system administrator can do what they need to do. I'll make that change, and once I get some last policy issues that I am seeing to work, I'll get the patch out. I'll try very hard to get that to happen this week. GW: alright, thank you much Matt. LK: if we don't have bugzillas for these two Matt, then we need to create some so the fixes will be pulled in MA: I have one, but I'll create another one and post to the list so people can keep track of it as well. Secmark -------- GW: any read if secmark will make it or not. last week Dan you said you think it might not make it. DW: current kernel fixes is in iptables. we are talking in RH to see if that goes into the release. if you guys want to put a push in to require it, then you have to do that. GW: I don't think we want to require it. DW: my own opinion is turn secmark on and put patches into fc6 and run with it, but I have concerns GW: yeah, we are all concerns, a big piece of venkat's work is reconciling the labels and we'll see the progress on that soon. the question is if we use the compatibility mode will RH support that? SG: if secmark is not available then compatibility mode is all we have left GW: It would be nice to see what is desirable and make that our direction, but its coming very late is creating the disturbance. And we don't know if it will be included or not. SG: I won't know until FC6 is cut GW: can we make a decision and say we want to support compatibility mode even if the changes in iptables happen? The good question is if it is there and secmark rules are generated then how will all this stuff hang together? SG: this should be part of our discussion tomorrow afternoon, but if it is a desirable feature then we probably have to wait until FC6 is cut before we know one way or another. GW: so for now we can't set up a final system, since it can go both ways. CIPSO ------ GW: ok, finally cipso, Paul any updates? PM: the patches were sent out last week; one of them is a couple of bug fixes. There is a change in selinux permission use for packets coming into system. The patches have not been accepted yet, but James Morris ack'd them. I expect them to go in if not today, then maybe tomorrow. I am working on a patch to add auditing for security relevant net label. I had discussion with Steve and I am implementing that. I'll send it to the list to get comments. I'll send to audit and net-dev, this is probably going to be this week. whatever time left I'll work on policy and user space. xinetd has come up as result of label networking discussion and as far as I know it's the only user. Stephen Smalley posted some concerns about that. Steve if you are still the xinetd maintainer, you might want to follow that discussion closely if you have not been already. LK: Paul is there a bugzilla for that ack. PM: no that was sent through a private note, but I'll create one. SG: I am the xinetd maintainer, but that discussion makes my head spin. xinetd I think is the only consumer of it, so people don't want to patch. PM: yeah, not complaining just bringing the thread to your attention in case you like to follow it. SG: I will, thanks IPsec ----- GW: So regarding Ipsec, we'll get a good discussion tomorrow hopefully. Anything you like to report Joy? JL: I sent out the racoon patches to mailing list; one person responded with a question, and I need to send him an answer. I also ran racoon patches against labeled and unlabeled IPsec and it passed ok. as far as labeled ipsec stuff, I am not really sure until we solve the other issues we'll talk about tomorrow. GW: what other issues do you think we still need to address? JL: The issue has come up to produce more fine grained messages. I think most of the functionality is there but we were discussing how to improve that VY: I was going to send the patch last week, but had few issues come up. it looks like in next day or so, I'll send a patch out. JL: if we do that, and produce more finer grained SA then it looks like we have similarity with cipso and don't see then why we need both of those together? KW: Joy and venkat, if you can post to list what the pieces are that we need to run with. In order to test, it is not clear what needs to be done. GW: Joy, can you send step by step instructions on what is needed a side from doing the beta refresh. JL: you mean how to configure IPsec? GW: yeah.. that is part of it, maybe also a link to the patch. JL: In the first two racoon patches I sent, I had a write up with instructions on how to set it up and use it. I can resend that. but everything you need to do as far as applying the patch and using the tool is in that email. KW: if things are all accurate still then it's fine, but if you can check to make sure all the steps/versions still apply and accurate that would help alot. JL: Ok, I'll check that. GW: thanks joy for doing that. Has anybody else attempted to set this up? I want to get gauge to see if there are sufficient instructions on how to set it up out there. JL: do you need instructions on how to configure IPsec, or how to use labeled IPsec? KW: maybe have instructions from point of a user who is not really interested in IPsec but wants to use it for labeled transport. JL: I might not be able to provide that. I can send instructions on how to add labels to policy, but what I can't provide is what you need to change on your system, for example policy KW: what we need is the MLS labels. what you need to do to get MLS rules enforced? GW: I would like to see a step by step recipe if anyone actually tries this. JL: I can do that, but can't do it tomorrow. GW: I need to do this as well. we need to try end to end with IPsec, xinetd, sshd, and polyinstantiation. It looks like klaus is the only one seriously working on that. KW: at this point we can't expect people to be using both IPsec and cipso at once. PM: the strange thing is that they probably work together right now. if you have both labeled IPsec and net label on the same connection. GW: that's what everyone is saying is that all pieces are there but the lack of information is causing us not to know how to set them up; we need to get that out there. Hopefully one of things that will come up tomorrow that pieces are there but just need to configure them properly and maybe write a bit of policy. xinetd ------- GW: Any issues with xinetd? KW: is there already info out there on how to set it up? SG: I updated the man page. I believe it's a flag that you need to set, aside from all the policy work. it's basically adding one line to configurations. KW: ok, thanks. Single-user mode ----------------- GW: not sure if that made it in SG: Dan had to leave. but I am not sure what the status of that is Self tests ----------- GW: I did not do anything on those. Steve, what about the intrusion detection package that you wanted me to put in? any progress on that? SG: Not much, I was working on tar; it is important and we need to get that working before getting to the extra stuff. GW: is that tar or star? SG: we fixed tar about 6 weeks ago to include extended attributes, as soon as James is done with that, then he'll be back working on the intrusion detection and it will be good enough to use. VFS polyinstantiation ---------------------- GW: this seems to work for some but not others KW: if you want to get polyinstantiation working in enforcing mode, it doesn't allow that. for example unshare requires capp_sysadm capabilities. does RH have plans to get polyinstantiation or namespace working out of the box? DW: I think we want to do that as a boolean if we have it out of the box. I have no problem putting that in policy, but govern it by boolean. KW: we can add that to our nice to have list. You need to be able to mount on fully instantiated directories and it needs to have appropriate labels to get that to work. that depends on local configurations on how you want it to work, so might not be reasonable to get that working out of the box. The next thing is I couldn't get polyinstantiation to work when login in through sshd; does anyone have that working? LK: Klaus, clearly you are ahead of where I am on testing. It looks like you found problems and have work arounds, can you post that somewhere KW: I can, but it is up to George? GW: yeah, I think this needs to be shared with the community and I am fully supportive of that. LK: Is this the type of info that needs to be in pam_namespace man page. maybe we need to fix the instructions there too. KW: who is maintaining pam_namespace now that we can't rely on Janak? GW: Janak is irreplaceable. I can't volunteer, let me think about that some more. We may be able to bother Janak a bit, but he is busy. yeah we do need to find a maintainer going forward. KW: In order to have this work properly, we might need to work with net labeling to have the right data, that involves alot of components to get that to work together. GW: I think we need to have a name to put as maintainer. As klaus is able to put info out, if others are experimenting and find things out, then we would appreciate seeing that info on the list as well. Thanks much klaus Cron, tmpwatch, mail, etc. -------------------------- GW: cron seems to be working Dan said. and I don't know if anyone has tested that with mail wrapper. Would it help if I put out a list of bugs. Irena mentioned that every issue needs to have a bug with "lspp" in title, so we can search on that. If there is a bug that you need but don't want to open, then I'd be happy to open a bug. I can also put a list out with the bugs if RH is ok with that IB: yes, that is ok George. I also opened all the bugs so anyone can look up the lspp bugs. George as far as the bugzilla account, do you have one? I couldn't find you. GW: yes I do, it is with email ltcgcw. IB: ok, I might have used another email GW: any other issues? alright I'll continue bug fixes. I think that all we have now are small fixes. Irena anything else you like to add. IB: not much. Just one thing, when you open a bug, also submit the test along with it, so I can use that to defend the acceptance of the bug. From ltcgcw at us.ibm.com Tue Sep 26 16:35:58 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Tue, 26 Sep 2006 11:35:58 -0500 Subject: [redhat-lspp] Re: Labeled networking telecon In-Reply-To: <20060926004445.GA19051@us.ibm.com> References: <20060926004445.GA19051@us.ibm.com> Message-ID: <20060926163558.GA28432@us.ibm.com> On Mon, Sep 25, 2006 at 07:44:45PM -0500, George C. Wilson wrote: > Today the LSPP telecon participants suggested that we have a separate meeting > to discuss labeled networking. We would have to hold it soon because the RHEL5 > cutoff date is approaching. IBM is willing to host using the same number as > the LSPP call. > > How about 1 PM CDT tomorrow, Tuesday, Sept. 26? I think we need at least the > core labeled networking experts from HP, IBM, NSA, Red Hat, Tresys, and TCS. > Please respond to me if you are willing to participate. Be sure to include > issues you want to see on the agenda. If 1 PM CDT tomorrow is bad for you, > please send a counterproposal. I will send out a notice at roughly 11 AM CDT > if we can get what looks like a quorum. If not, I will suggest a new time > based on the responses. > I have received only a limited number of responses. None, however, suggested we needed an alternate time. I understand that notice is short and not everyone agrees a call is useful. Given the urgency Red Hat has expressed in meeting their schedule, we will go ahead with the call. I'll send the number to all the respondents. If you are on the LSPP call, please feel free to phone in even if you haven't responded. If you need the number, please let me know. We will post a summary of the discussion. Agenda items so far: - Only a handful of people have the time and skills to build a system with the appropriate patches and provide feedback - IPSec labeling end-to-end architecture - Interaction of Netlabel and IPSec with Secmark - Interaction with IPSec/Netlabel on same interface - How to set a default label for a single machine (think Windows XP) - How to set a default label for a network (IP/MASK) - How to set a default label for a network interface - getpeercon semantic consistency across the following - localhost IP sockets - Unix domain sockets - IPSec to remote machine with same security policy - Netlabel - getpeercon meaning - personal preference is peer _socket_ context, that would be consistent with the CMWs that we use today - Test schedule - When will Venkat's patch that allows getpeercon to work on local and IPSec IP sockets be in a kernel RPM? - When will a working context negotiating raccoon be in an RPM? -- George Wilson IBM Linux Technology Center From linda.knippers at hp.com Wed Sep 27 16:21:17 2006 From: linda.knippers at hp.com (Linda Knippers) Date: Wed, 27 Sep 2006 12:21:17 -0400 Subject: [redhat-lspp] mcstransd question Message-ID: <451AA4FD.7020508@hp.com> Are only users cleared to SystemHigh supposed to be able to see translated labels? That seems to be the way it works right now with mcstransd. The unix domain socket between libselinux and mcstransd is SystemHigh so while commands (ls -Z) run on behalf of a regular user (default SystemLow) try to translate the labels and can write the request to the socket but the daemon can't send the response. For example, this works: [root at kipper ~]# ls -lZd /bin drwxr-xr-x root root system_u:object_r:bin_t:SystemLow /bin This doesn't: [ljk at kipper ~]$ ls -lZd /bin drwxr-xr-x root root system_u:object_r:bin_t:s0 /bin and generates these: type=AVC msg=audit(1159373436.221:602): avc: denied { write } for pid=1862 comm="mcstransd" name="[9948]" dev=sockfs ino=9948 scontext=system_u:system_r:setrans_t:s15:c0.c1023 tcontext=system_u:system_r:setrans_t:s0 tclass=unix_stream_socket type=SYSCALL msg=audit(1159373436.221:602): arch=40000003 syscall=146 success=no exit=-13 a0=5 a1=bfa03dc8 a2=3 a3=3 items=0 ppid=1 pid=1862 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) comm="mcstransd" exe="/sbin/mcstransd" subj=system_u:system_r:setrans_t:s15:c0.c1023 key=(null) type=AVC_PATH msg=audit(1159373436.221:602): path="socket:[9948]" The socket looks like this: bash-3.1# ls -alZ /var/run/setrans/.setrans-unix srwxrwxrwx root root system_u:object_r:setrans_var_run_t:SystemHigh /var/run/setrans/.setrans-unix -- ljk From sgrubb at redhat.com Wed Sep 27 19:34:23 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Wed, 27 Sep 2006 15:34:23 -0400 Subject: [redhat-lspp] Updated iptables for secmark testing Message-ID: <200609271534.23884.sgrubb@redhat.com> Hi, Just wanted to mention that updated iptables rpms can be gotten from the lspp yum repo. http://people.redhat.com/sgrubb/files/lspp This rpm is needed to test the secmark iptables rules. -Steve From ltcgcw at us.ibm.com Thu Sep 28 00:13:07 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Wed, 27 Sep 2006 19:13:07 -0500 Subject: [redhat-lspp] Labeled Networking Telecon Notes Message-ID: <20060928001306.GA12728@us.ibm.com> Following are notes I took yesterday. I hope they aren't too cryptic or inaccurate to be useful. -- George Labeled Networking Telecon Notes - Tuesday, September 26, 2006 Attendees: Joshua Brindle Darrel Goeddel Steve Grubb Chad Hanson Linda Knippers Joy Latten Karl MacMillan Paul Moore Joe Nall Eric Paris Chris PeBenito Casey Schaufler Steve Smalley Ted Toth Dan Walsh Klaus Weidner George Wilson Kris Wilson Larry Wilson Venkat Yekkirala (There were additional folks on the call whose names I didn't get.) George: The big problem is there seems to be no overall architecture. Joshua: One problem is reading remote socket contexts. Not working as expected. Can propagate types w/Joy's patch. But not initiator connect context on server side. All 4 SA entries are labeled the same. Venkat: That will change once initiator context patch is in. Will use those as SA context. Joshua: So we will be able to get the server context? What about when the context doesn't exist on the local machine. Strict vs. targeted, for example: types exist on one that don't on the other. When labeling SPD entries, the must be valid on local machine. They are not guaranteed to exist, though. Klaus: A context must be valid on system using it. You want info about the process to use as the basis for making decisions. That is different from how SELinux works. Joshua: For CIPSO, there must be label translation. It is the way labeled networking traditionally works. Need to propagate labels from non-overlapping contexts. Karl: Stage in CIPSO is before it gets to SELinux. Should be kept separate. Need an info service, but not necessarily through SELinux. Karl: Policy will take care of it in vast majority of cases. Can just alias types. Joshua: That makes it hard. Karl: Will be doing it in policy. Anything more is outside the scope of present work. Klaus: Can we agree that the labels need to be valid on machine it is coming from? SDS: SELinux only returns contexts valid on the local system. Klaus: Need a translation layer before it gets to SELinux. Joshua: Don't want invalid context; need remote context to send context to local machine. Karl: Whether it deals on local or remote doesn't matter - one will be invalid on the other. Joshua: Yes, translation happens in the middle. Karl: That is research-oriented. Casey: TSIX is a working example. Karl: When will the latest stuff with secmark doing what IPsec is doing be available? Primarily translating info about endpoint - labels on packet differentiated from label on socket. Venkat: SAs are not packet labels anymore; they're really socket labels according to configured policy. Can enforce getpeercon() semantics - shouldn't be implied domain - can check and fail. Karl: Even w/IPsec, can set arbitrary contexts on packet, which may be different from context on socket. Venkat: That will no longer be true very soon. Will look for SA that matches socket, then will call out to racoon. Joshua: Are you planning on changing SA initiation to do it per-domain? Venkat: You mean getting the domain from policy? Joshua: So it would be per-domain. Venkat: That is correct. Karl: Really, those are per-socket contexts, not per-domain. Joshua: That sounds right. Karl: Remaining concern is reconciliation w/secmark. The existing secmark implementation is confusing. Endpoints are more intuitive. Joshua: So is existing method of labeling sockets wrong? Venkat: It's carrying the remote domain rather than socket label. SDS: We'll need to rework this in the reference policy. Karl: have httpd_t, httpd_packet_t; client would be separate. Policy works the same for all labeled mechanisms. Joshua: Secmark is more general. You could stick any other label in there. It has nothing to do with a domain. Karl: Now it's discriminating based on data type; but could discriminate based on endpoint - network topology. Joshua: How does that work? Karl: If you have 2 apaches and 2 domains. Joshua: 2 clients would be using the same port - how to differentiate? Karl: May not be able to w/secmark. With IPsec they are differentiated. Have refinement of same model. Joshua: If using iptables rules to do this, how do we use the rules to differentiate say mozilla_t from aggregator_t. Karl: May not be able to without knowledge of network topology. If it does use secpoint, they will become httpd_client_t. If it receives and IPsec client connection, might be able to differentiate between types. Venkat: Policy will have to express real remote domain. There will be a check whereby no random IPsec domain can set the type. Karl: We could use type transition rules to collapse to them all to http_obj_t if necessary. The rules will be similar no matter what you are doing. It's still endpoint- oriented. IPsec and secmark are different ways of accomplishing differentiation. Joshua: When you have rules applied to connections, you will have different obj classes. Policy has same thing happening, but applying to different objects. Reconcile objects? Venkat: Peer-class. Refinement will give that to you. Joshua: What about packet and assoc obj classes? Venkat: We can retain those checks. Joshua: Don't need to get rid of them entirely. Venkat: Reconciliation patch has receive compat function. Joshua: Since we have peer obj class, will we reconcile local peercon answers? Will we have local peer contexts? What about Unix domain, local sockets? Would we use getpeercon() for all lookups from now on? Venkat: Yes, origination domain should come through. Paul: I'm happy with this. Joshua: It's very good for our purposes. Karl: This solves a number of things - not shipping multiple policies. Will it be clear to secmark users that iptables rules may no longer be in effect. 1st time we'll have overlapping label rules. Joshua: Won't get unexpected connection that blows away old label if policy dictates that label must be of similar types? Distro policy can have default policy on where to get labels. Karl: Sounds like good idea. Need to make sure object class models are clear. Joshua: This reconciles secmark and IPsec. What about CIPSO? Venkat: Could be used with ranged SAs. It's almost natural. Joshua: The level thing is fine. But when CIPSO supports full contexts, what happens? Venkat: Paul would discourage using CIPSO and IPsec together. CIPSO is for legacy. Paul: 2 issues - 1. What to do when just CIPSO on connection w/secmark. About the only reasonable think to do is take TE part of context from secmark from flow in and concat MLS label from CIPSO connection. Not too different from IPsec proposal for IPsec from Venkat. Joshua: Need to add rules to flow through. Paul: Right. Not too different from secmark-only case; just adjust label. Casey: That's in line with the way MLS systems traditionally used networking. Paul: Not that shocking. 2. What do you do if you have IPsec on commmo channel as well. Need some discussion on thread. Venkat: Would take TE portion from secmark; by that time IPsec connection already resolved. Already have that point to refinement. Paul: Point is - do we want to allow IPsec and CIPSO on same connection? Joshua: Use case? Casey: TSIX world - 1 vendor decided they wanted CIPSO and SAMP labels; CIPSO for range checking - TSIX SAMP labels used after CIPSO's. In general, pick one or the other. Paul: That is similar to what SDS was saying: additional check on the label. >From my POV, it's just taking what is in secmark no matter where it came from. Question becomes do we want to blindly throw away what is in the secmark label or have a check between the two - iptables throw away; IPsec throw away. Darrel: Should always have check - CIPSO. Venkat: New patch is kernel patch. Steve Grubb: We have a tight deadline on kernel patches. Paul: Will need day or 2 after IPsec patch. Joshua: What about racoon after Venkat's patch? Venkat: Expect no changes to Joy's patch as result of SA context Eric: If we don't have code by Friday, this mostly dead. Venkat: Seems like reasonable goal. Will have a patch out tomorrow. Paul: As soon as we can get patch, that will help me. Venkat: Correct secid reconciliation is pretty close to done. Just pieces here and there. Dan: Great - not packets, endpoints. Must write rules; or will it be taken care of for us? Do I have to say something in iptables? Karl: You will have to have iptables rules. Dan: How to label? Joshua: Would have labels applied by secmark. Could make inet labels of localhost take label of local socket. Venkat: Will be carried with local host. Chad: Like forwarding case - already have label. Karl: Iptables rules will only be used for external packets coming in? Venkat: Can define in secpoint as well. Karl: Overriding of existing label? All sending packets will take socket context - in absence of secmark labels you need flow out checks. Venkat: Once past loopback, makes no sense to override existing labels. That part will have to be ignored. Dan: Don't know if that answers question. Karl: Will have similar # of rules as with secmark today. Dan: Sigh. Karl: We don't have a way to get labels from the outside world other than IPsec. Dan: Can we write particular rules? Chad: There is no way to simplify writing policy, really. Karl: Name bind and name connect are unaffected. Will still have node and netif? Steve Smalley: Only for bind checks. Dan: I still see an issue with booleans. Will we have to load a bunch of iptables rules? I don't know how this is going to work in practice. This is an improvement; userspace will require modification. George: Will this work be completed in time for the RHEL5 cutoff? Steve Grubb: Leaning towards enabling kernel pieces; will work through it. But leaning towards 5.1 for userspace. Karl: Would be new way of enabling security. Joshua: 5.0 could ship w/o secmark. Kernel will be the same - just userspace mods would be required. Wait to introduce network management until 5.1. Dan: Targeted policy is freeflow until users turns it on - unlabeled packets w/o mangling rules. We lose a lot by not getting it in. Similar problem w/compat mode. Compat mode needs stuff written, too. You would have to write your own policy modules. George: So I hear us leaning towards compat mode? Steve Grubb: We have more time on userspace. If somebody works through them quickly it could happen. I don't know who's working on it . . . Paul: Only 1 week difference between kernel and userspace cutoffs, I thought. Linda: Just joined. Sounds like we are talking about tools to use secmark in compat mode or not. Geo: We will writing policy no matter what now. Linda: Why? Dan: If you want to control, you need either secmark or IPsec rules. Klaus: Dealing w/MLS rules. From a certification POV, it is not necessary to be concerned about TE or domains to be LSPP compliant. Karl: Sounds like we're OK so long as compat mode is off. MLS constraints will still work. Klaus: If all packets get default labels, MLS rules should make decisions. We don't need to care about TE. Karl: We need a big boolean to allow labeled networking to work even when the firewall is down. Need applications to continue to work if admins want to do that. Klaus: We still need a way to reject unlabeled connections. Karl: Goes back to discussion of needing separate SID on packets for unlabeled vs default labels. Klaus: Default label would in theory be OK, so long as it is incompatible with other labels. Joshua: If you bring down the firewall, that would be setting the rules to accept; no secmark anywhere at all? Casey: That sounds like it would be dangerous. Dealt with granularity of host default label before. Karl: We're talking about targeted; don't know what to do for strict. If we put boolean and nothing matches, it will get the unlabeled SID. ???: If the firewall goes down, we should reject everything. Karl: Boolean would allow unlabeled networking. Want iptables init script to turn that to true as the firewall goes down. If we don't flip it in LSPP, nothing will receive unlabeled packets. Sounds like should have everything on by default in RHEL5 without rules. Dan: LSPP only cares about MLS. Wouldn't have to use mangle rules? Karl: Would have to pass unlabeled allow rule to get to MLS constraints. Dan: Unlabeled packets means they are all at SystemLow, unlabeled_t. I'm not talking about IPsec; I'm talking about packets able to flow on single machine. Don't have to turn on TE. Could say everything coming in on interface 1 is unlabeled_t:secret. Klaus: Would ignore TE; just look at connection; can add TE later. Karl: "Allow unlabeled packets or any other label" would be the actual boolean. MLS would do its normal thing. The easiest thing is to turn everything on. Steve Grubb: Dunno if maint will apply the patch if have to change significantly between 5.0 and 5.1. Karl: Nothing changes in iptables. The patches are already in head. That's the one that doesn't change. How are we going to turn rules on by default is only question. He's already applied the patches - change "secmark" to "secpoint" name is only issue. Most of the IPsec stuff is there. There's really just one change left for that. Most everything is in. Steve Grubb: Racoon patches were being compiled this AM; should be pulled over into rawhide. Karl: So far as iptables work, will post when that is ready. Venkat: Secmark is done. Reconciliation patches will fix case with multiple labeling mechanisms. Karl: We're not depending on it for unlabeled packets. Klaus: Would still be using secmark rules? Karl: No rules for secmark. Klaus: If all LSPP features work w/o firewall, I suppose we don't. George: Need documentation for arch and setup instructions. Klaus: Need to know kernel, tools, versions, etc. (Misc. chatter I didn't document.) -- George Wilson IBM Linux Technology Center From jmorris at redhat.com Thu Sep 28 14:37:30 2006 From: jmorris at redhat.com (James Morris) Date: Thu, 28 Sep 2006 10:37:30 -0400 (EDT) Subject: [redhat-lspp] Labeled Networking Telecon Notes In-Reply-To: <20060928001306.GA12728@us.ibm.com> Message-ID: On Wed, 27 Sep 2006, George C. Wilson wrote: > George: The big problem is there seems to be no overall architecture. Just to clarify, because I'm not sure if it was on the call, we asked for and received an architecture document upstream from Venkat: http://marc.theaimsgroup.com/?l=linux-netdev&m=115136637800361&w=2 -- James Morris From dwalsh at redhat.com Thu Sep 28 15:00:42 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 28 Sep 2006 11:00:42 -0400 Subject: [redhat-lspp] Re: mcstransd question In-Reply-To: <451AA4FD.7020508@hp.com> References: <451AA4FD.7020508@hp.com> Message-ID: <451BE39A.1080104@redhat.com> Linda Knippers wrote: > Are only users cleared to SystemHigh supposed to be able to see translated > labels? > > That seems to be the way it works right now with mcstransd. The unix > domain socket between libselinux and mcstransd is SystemHigh so while > commands (ls -Z) run on behalf of a regular user (default SystemLow) > try to translate the labels and can write the request to the socket > but the daemon can't send the response. > > For example, this works: > [root at kipper ~]# ls -lZd /bin > drwxr-xr-x root root system_u:object_r:bin_t:SystemLow /bin > > This doesn't: > [ljk at kipper ~]$ ls -lZd /bin > drwxr-xr-x root root system_u:object_r:bin_t:s0 /bin > > This is broken. I am not sure how to handle this? I have changed it back to SystemLow-SystemHigh which allows it to work properly but I think we need some constraints to prevent someone from getting translations at a higher level then they are authorized for. > and generates these: > > type=AVC msg=audit(1159373436.221:602): avc: denied { write } for pid=1862 > comm="mcstransd" name="[9948]" dev=sockfs ino=9948 > scontext=system_u:system_r:setrans_t:s15:c0.c1023 > tcontext=system_u:system_r:setrans_t:s0 tclass=unix_stream_socket > type=SYSCALL msg=audit(1159373436.221:602): arch=40000003 syscall=146 success=no > exit=-13 a0=5 a1=bfa03dc8 a2=3 a3=3 items=0 ppid=1 pid=1862 auid=4294967295 > uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) > comm="mcstransd" exe="/sbin/mcstransd" > subj=system_u:system_r:setrans_t:s15:c0.c1023 key=(null) > type=AVC_PATH msg=audit(1159373436.221:602): path="socket:[9948]" > > The socket looks like this: > bash-3.1# ls -alZ /var/run/setrans/.setrans-unix > srwxrwxrwx root root system_u:object_r:setrans_var_run_t:SystemHigh > /var/run/setrans/.setrans-unix > > I > -- ljk > From paul.moore at hp.com Thu Sep 28 15:06:40 2006 From: paul.moore at hp.com (Paul Moore) Date: Thu, 28 Sep 2006 11:06:40 -0400 Subject: [redhat-lspp] Re: mcstransd question In-Reply-To: <451BE39A.1080104@redhat.com> References: <451AA4FD.7020508@hp.com> <451BE39A.1080104@redhat.com> Message-ID: <451BE500.2020202@hp.com> Daniel J Walsh wrote: > Linda Knippers wrote: > >>Are only users cleared to SystemHigh supposed to be able to see translated >>labels? >> >>That seems to be the way it works right now with mcstransd. The unix >>domain socket between libselinux and mcstransd is SystemHigh so while >>commands (ls -Z) run on behalf of a regular user (default SystemLow) >>try to translate the labels and can write the request to the socket >>but the daemon can't send the response. >> >>For example, this works: >>[root at kipper ~]# ls -lZd /bin >>drwxr-xr-x root root system_u:object_r:bin_t:SystemLow /bin >> >>This doesn't: >>[ljk at kipper ~]$ ls -lZd /bin >>drwxr-xr-x root root system_u:object_r:bin_t:s0 /bin >> >> > > This is broken. I am not sure how to handle this? I have changed it > back to SystemLow-SystemHigh > which allows it to work properly but I think we need some constraints to > prevent someone from getting translations at a higher level then they > are authorized for. The translation daemon is a trusted program, yes? If so, could we have it do a getpeercon() call to determine the context of the app requesting the translation and then do a permissions check to see if the returned translation is allowed? At first glance this seems easier than some of the alternatives ... -- paul moore linux security @ hp From linda.knippers at hp.com Thu Sep 28 15:09:00 2006 From: linda.knippers at hp.com (Linda Knippers) Date: Thu, 28 Sep 2006 11:09:00 -0400 Subject: [redhat-lspp] Re: mcstransd question In-Reply-To: <451BE500.2020202@hp.com> References: <451AA4FD.7020508@hp.com> <451BE39A.1080104@redhat.com> <451BE500.2020202@hp.com> Message-ID: <451BE58C.1050708@hp.com> Paul Moore wrote: > Daniel J Walsh wrote: > >>Linda Knippers wrote: >> >> >>>Are only users cleared to SystemHigh supposed to be able to see translated >>>labels? >>> >>>That seems to be the way it works right now with mcstransd. The unix >>>domain socket between libselinux and mcstransd is SystemHigh so while >>>commands (ls -Z) run on behalf of a regular user (default SystemLow) >>>try to translate the labels and can write the request to the socket >>>but the daemon can't send the response. >>> >>>For example, this works: >>>[root at kipper ~]# ls -lZd /bin >>>drwxr-xr-x root root system_u:object_r:bin_t:SystemLow /bin >>> >>>This doesn't: >>>[ljk at kipper ~]$ ls -lZd /bin >>>drwxr-xr-x root root system_u:object_r:bin_t:s0 /bin >>> >>> >> >>This is broken. I am not sure how to handle this? I have changed it >>back to SystemLow-SystemHigh >>which allows it to work properly but I think we need some constraints to >>prevent someone from getting translations at a higher level then they >>are authorized for. > > > The translation daemon is a trusted program, yes? If so, could we have > it do a getpeercon() call to determine the context of the app requesting > the translation and then do a permissions check to see if the returned > translation is allowed? At first glance this seems easier than some of > the alternatives ... > I was looking at that too. I think the daemon already gets that information (it has a get_peer_con() function) so perhaps all that's missing is the permission check. -- ljk From sds at tycho.nsa.gov Thu Sep 28 17:52:13 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 28 Sep 2006 13:52:13 -0400 Subject: [redhat-lspp] Re: mcstransd question In-Reply-To: <451BE58C.1050708@hp.com> References: <451AA4FD.7020508@hp.com> <451BE39A.1080104@redhat.com> <451BE500.2020202@hp.com> <451BE58C.1050708@hp.com> Message-ID: <1159465933.13131.10.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-09-28 at 11:09 -0400, Linda Knippers wrote: > Paul Moore wrote: > > Daniel J Walsh wrote: > > > >>Linda Knippers wrote: > >> > >> > >>>Are only users cleared to SystemHigh supposed to be able to see translated > >>>labels? > >>> > >>>That seems to be the way it works right now with mcstransd. The unix > >>>domain socket between libselinux and mcstransd is SystemHigh so while > >>>commands (ls -Z) run on behalf of a regular user (default SystemLow) > >>>try to translate the labels and can write the request to the socket > >>>but the daemon can't send the response. > >>> > >>>For example, this works: > >>>[root at kipper ~]# ls -lZd /bin > >>>drwxr-xr-x root root system_u:object_r:bin_t:SystemLow /bin > >>> > >>>This doesn't: > >>>[ljk at kipper ~]$ ls -lZd /bin > >>>drwxr-xr-x root root system_u:object_r:bin_t:s0 /bin > >>> > >>> > >> > >>This is broken. I am not sure how to handle this? I have changed it > >>back to SystemLow-SystemHigh > >>which allows it to work properly but I think we need some constraints to > >>prevent someone from getting translations at a higher level then they > >>are authorized for. > > > > > > The translation daemon is a trusted program, yes? If so, could we have > > it do a getpeercon() call to determine the context of the app requesting > > the translation and then do a permissions check to see if the returned > > translation is allowed? At first glance this seems easier than some of > > the alternatives ... > > > > I was looking at that too. I think the daemon already gets that information > (it has a get_peer_con() function) so perhaps all that's missing is the > permission check. Yes, and that would just be an avc_has_perm() call on the pair of contexts. BTW, as I've previously noted, it should be using getpeercon(3), not getpidcon(3). -- Stephen Smalley National Security Agency From thompsmc at us.ibm.com Thu Sep 28 18:10:21 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Thu, 28 Sep 2006 13:10:21 -0500 Subject: [redhat-lspp] Newrole failure yeilds no audit record In-Reply-To: <200609151957.k8FJvYHG026324@turing-police.cc.vt.edu> References: <4509BF1C.7070603@us.ibm.com> <200609151516.08100.sgrubb@redhat.com> <1158348505.18951.130.camel@moss-spartans.epoch.ncsc.mil> <200609151536.49217.sgrubb@redhat.com> <200609151957.k8FJvYHG026324@turing-police.cc.vt.edu> Message-ID: <451C100D.1030005@us.ibm.com> Valdis.Kletnieks at vt.edu wrote: > On Fri, 15 Sep 2006 15:36:49 EDT, Steve Grubb said: >> On Friday 15 September 2006 15:28, Stephen Smalley wrote: >>> Are you sure? ? What do you want to audit? >>> newrole -r typoinrolename ? >>> newrole -r sysadm_r for user not authorized for that role? >>> any error exit path out of newrole? >>> >>> The first two cases look exactly identical to newrole btw - it just gets >>> an error from security_check_context() telling it that the context >>> wasn't valid, not why. >> I think we only need to say that the result was a failure. We do not need to >> say why it failed. I'm currently working on newrole in Janak's stead, and it seems to me that the only place it would make sense to report a failure is when the new context's validation check fails. > Does it make sense to just log what information we *do* know, and hope there's > enough for a human to tell what happened? Or does this run into the same sort > of data-disclosure issues that logging the userid on invalid password attempts > has (namely, that if the user has gotten "out of sync", they may type their > password in response to the Userid: prompt and cause it to be logged in > cleartext). Or should security_check_context() return a more featureful > return code in case of an error? Before the user has authenticated, the only point of failure which is policy related is obtaining the default type for a role if the type is left unspecified. I do not see this as an error worthy of auditing, since I frequently mistype my intended role. After authentication, the new context's validation check occurs, and I feel that this is the first point where auditing becomes reasonable. After this check, almost all subsequent points of failure are due to errors I would consider to be unexpected (e.g. ENOMEM), although some are due to relabeling the tty, which can fail in enforcing mode. We already have AVC messages which handle this, but should this failure be audited? In short, I would recommend add auditing if the new context's validation check fails, and retain the auditing of success as it is now. Would this logging the failed attempt post-authentication sufficient? Thanks, Mike From linda.knippers at hp.com Thu Sep 28 18:33:55 2006 From: linda.knippers at hp.com (Linda Knippers) Date: Thu, 28 Sep 2006 14:33:55 -0400 Subject: [redhat-lspp] Re: mcstransd question In-Reply-To: <1159465933.13131.10.camel@moss-spartans.epoch.ncsc.mil> References: <451AA4FD.7020508@hp.com> <451BE39A.1080104@redhat.com> <451BE500.2020202@hp.com> <451BE58C.1050708@hp.com> <1159465933.13131.10.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <451C1593.7010604@hp.com> Stephen Smalley wrote: >>>>This is broken. I am not sure how to handle this? I have changed it >>>>back to SystemLow-SystemHigh >>>>which allows it to work properly but I think we need some constraints to >>>>prevent someone from getting translations at a higher level then they >>>>are authorized for. >>> >>> >>>The translation daemon is a trusted program, yes? If so, could we have >>>it do a getpeercon() call to determine the context of the app requesting >>>the translation and then do a permissions check to see if the returned >>>translation is allowed? At first glance this seems easier than some of >>>the alternatives ... >>> >> >>I was looking at that too. I think the daemon already gets that information >>(it has a get_peer_con() function) so perhaps all that's missing is the >>permission check. > > > Yes, and that would just be an avc_has_perm() call on the pair of > contexts. Its a little more complicated than that because avc_has_perm() takes you down a path where it wants to translate a context. avc_had_perm() calls avc_has_perm_noaudit() and if the avc_lookup() fails, it calls security_compute_av(), which needs a raw context so it calls back into the translation functions. I think I can make it work by calling security_compute_av_raw() instead but then it doesn't get cached, right? Any other ideas? > > BTW, as I've previously noted, it should be using getpeercon(3), not > getpidcon(3). > From sgrubb at redhat.com Thu Sep 28 18:56:33 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 28 Sep 2006 14:56:33 -0400 Subject: [redhat-lspp] Newrole failure yeilds no audit record In-Reply-To: <451C100D.1030005@us.ibm.com> References: <4509BF1C.7070603@us.ibm.com> <200609151957.k8FJvYHG026324@turing-police.cc.vt.edu> <451C100D.1030005@us.ibm.com> Message-ID: <200609281456.33368.sgrubb@redhat.com> On Thursday 28 September 2006 14:10, Michael C Thompson wrote: > Before the user has authenticated, the only point of failure which is > policy related is obtaining the default type for a role if the type is > left unspecified. I do not see this as an error worthy of auditing, > since I frequently mistype my intended role. I think we want to capture these since it would be a way for people to probe the policy without being caught. > After this check, almost all subsequent points of failure are due to > errors I would consider to be unexpected (e.g. ENOMEM), although some > are due to relabeling the tty, which can fail in enforcing mode. We > already have AVC messages which handle this, but should this failure be > audited? I think all failures due to user actions should be reported in audit message. Failures due to system resource exhaustion shouldn't be. The AVC does not substitute for a newrole originating message since you have to infer what the outcome was. -Steve From sds at tycho.nsa.gov Thu Sep 28 19:12:05 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 28 Sep 2006 15:12:05 -0400 Subject: [redhat-lspp] Re: mcstransd question In-Reply-To: <451C1593.7010604@hp.com> References: <451AA4FD.7020508@hp.com> <451BE39A.1080104@redhat.com> <451BE500.2020202@hp.com> <451BE58C.1050708@hp.com> <1159465933.13131.10.camel@moss-spartans.epoch.ncsc.mil> <451C1593.7010604@hp.com> Message-ID: <1159470725.13831.36.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-09-28 at 14:33 -0400, Linda Knippers wrote: > Its a little more complicated than that because avc_has_perm() takes > you down a path where it wants to translate a context. > > avc_had_perm() calls avc_has_perm_noaudit() and if the avc_lookup() > fails, it calls security_compute_av(), which needs a raw context > so it calls back into the translation functions. > > I think I can make it work by calling security_compute_av_raw() > instead but then it doesn't get cached, right? > > Any other ideas? Hmmm..context translation support wasn't properly integrated with the userspace AVC. Logically, I'd expect avc_context_to_sid() and avc_sid_to_context() to perform translation, such that avc_has_perm_noaudit() would already have the raw contexts available to it from the SIDs and be able to directly call security_compute_av_raw() internally. And then one would have avc_context_to_sid_raw() and avc_sid_to_context_raw() for programs that didn't want translation at all. For the translation daemon itself, you might want a libselinux function that lets you disable all translations (i.e. set a flag that is checked on entry by selinux_trans_to_raw_context() and selinux_raw_to_trans_context() and handled in the same manner as the ! mls_enabled case). Then the translation daemon could just call any libselinux function without needing to worry about accidentally triggering a communication to itself. -- Stephen Smalley National Security Agency From thompsmc at us.ibm.com Thu Sep 28 19:37:23 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Thu, 28 Sep 2006 14:37:23 -0500 Subject: [redhat-lspp] [PATCH] newrole auditing of failures due to user actions Message-ID: <451C2473.7050102@us.ibm.com> This patch introduces two new point in the code where audit records are generated for newrole. Both points are when the attempt to newrole fails. The first point is when the default type could not be determine for the specified role - this is audited because, as sgrubb pointed out, it is currently non-tracked path to probe the policy. The second point is when the desired context to change to is invalid. There record format remains unchanged. Failing to validate the desired context will result in the old and new contexts being recorded intact to the log. For the default type, the old and new contexts have not yet been obtained, so they are recorded in the log as XXX_context=? Signed-off-by: Michael Thompson ---- -------------- next part -------------- A non-text attachment was scrubbed... Name: newrole_audit_fail.patch Type: text/x-diff Size: 2752 bytes Desc: not available URL: From thompsmc at us.ibm.com Thu Sep 28 20:05:23 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Thu, 28 Sep 2006 15:05:23 -0500 Subject: [redhat-lspp] Re: [PATCH] newrole auditing of failures due to user actions In-Reply-To: <451C2473.7050102@us.ibm.com> References: <451C2473.7050102@us.ibm.com> Message-ID: <451C2B03.1060300@us.ibm.com> Michael C Thompson wrote: > This patch introduces two new point in the code where audit records are > generated for newrole. Both points are when the attempt to newrole fails. Forgot to copy the SELinux mailing list. > The first point is when the default type could not be determine for the > specified role - this is audited because, as sgrubb pointed out, it is > currently non-tracked path to probe the policy. > > The second point is when the desired context to change to is invalid. > > There record format remains unchanged. Failing to validate the desired > context will result in the old and new contexts being recorded intact to > the log. For the default type, the old and new contexts have not yet > been obtained, so they are recorded in the log as XXX_context=? > > Signed-off-by: Michael Thompson > > ---- > > > > ------------------------------------------------------------------------ > > --- policycoreutils-1.30.29/newrole/newrole.c 2006-09-14 07:07:26.000000000 -0500 > +++ policycoreutils-1.30.29.orig.dev/newrole/newrole.c 2006-09-28 14:21:27.000000000 -0500 > @@ -47,7 +47,9 @@ > * > *************************************************************************/ > > +#ifndef _GNU_SOURCE > #define _GNU_SOURCE > +#endif > #include > #include /* for malloc(), realloc(), free() */ > #include /* for getpwuid() */ > @@ -394,6 +396,41 @@ > cap_free(new_caps); > } > } > + > +/* Send audit message */ > +int send_audit_message(int success, security_context_t old_context, > + security_context_t new_context, const char *ttyn) > +{ > + char *msg = NULL; > + int rc; > + int audit_fd = audit_open(); > + > + if (audit_fd < 0) { > + fprintf(stderr, _("Error connecting to audit system.\n")); > + rc = -1; > + goto out; > + } > + if (asprintf(&msg, "newrole: old-context=%s new-context=%s", > + old_context ? old_context : "?", > + new_context ? new_context : "?") < 0) { > + fprintf(stderr, _("Error allocating memory.\n")); > + rc = -1; > + goto out; > + } > + rc = audit_log_user_message(audit_fd, AUDIT_USER_ROLE_CHANGE, > + msg, NULL, NULL, ttyn, success); > + if (rc <= 0) { > + fprintf(stderr, _("Error sending audit message.\n")); > + rc = -1; > + goto out; > + } > + rc = 0; > +out: > + free(msg); > + close(audit_fd); > + return rc; > +} > + > #endif > > /************************************************************************ > @@ -536,6 +573,9 @@ > if (role_s && !type_s) { > if (get_default_type(role_s, &type_s)) { > fprintf(stderr, _("Couldn't get default type.\n")); > +#ifdef LOG_AUDIT_PRIV > + send_audit_message(0, old_context, new_context, ttyn); > +#endif > exit(-1); > } > #ifdef CANTSPELLGDB > @@ -715,6 +755,9 @@ > > if (security_check_context(new_context) < 0) { > fprintf(stderr, _("%s is not a valid context\n"), new_context); > +#ifdef LOG_AUDIT_PRIV > + send_audit_message(0, old_context, new_context, ttyn); > +#endif > exit(-1); > } > > @@ -874,30 +917,8 @@ > exit(-1); > } > #ifdef LOG_AUDIT_PRIV > - /* Send audit message */ > - { > - char *msg; > - int rc; > - int audit_fd = audit_open(); > - if (audit_fd < 0) { > - fprintf(stderr, > - _("Error connecting to audit system.\n")); > - exit(-1); > - } > - if (asprintf(&msg, "newrole: old-context=%s new-context=%s", > - old_context, new_context) < 0) { > - fprintf(stderr, _("Error allocating memory.\n")); > - exit(-1); > - } > - rc = audit_log_user_message(audit_fd, AUDIT_USER_ROLE_CHANGE, > - msg, NULL, NULL, ttyn, 1); > - if (rc <= 0) { > - fprintf(stderr, _("Error sending audit message.\n")); > - exit(-1); > - } > - free(msg); > - close(audit_fd); > - } > + if (send_audit_message(1, old_context, new_context, ttyn)) > + exit(-1); > #endif > freecon(old_context); > execv(pw->pw_shell, argv + optind - 1); > > > ------------------------------------------------------------------------ > > -- > Linux-audit mailing list > Linux-audit at redhat.com > https://www.redhat.com/mailman/listinfo/linux-audit From sds at tycho.nsa.gov Thu Sep 28 20:10:57 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 28 Sep 2006 16:10:57 -0400 Subject: [redhat-lspp] [PATCH] newrole auditing of failures due to user actions In-Reply-To: <451C2473.7050102@us.ibm.com> References: <451C2473.7050102@us.ibm.com> Message-ID: <1159474257.13831.44.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-09-28 at 14:37 -0500, Michael C Thompson wrote: > This patch introduces two new point in the code where audit records are > generated for newrole. Both points are when the attempt to newrole fails. > > The first point is when the default type could not be determine for the > specified role - this is audited because, as sgrubb pointed out, it is > currently non-tracked path to probe the policy. > > The second point is when the desired context to change to is invalid. > > There record format remains unchanged. Failing to validate the desired > context will result in the old and new contexts being recorded intact to > the log. For the default type, the old and new contexts have not yet > been obtained, so they are recorded in the log as XXX_context=? > > Signed-off-by: Michael Thompson (note: needs to go to selinux list if you want it merged) --- policycoreutils-1.30.29/newrole/newrole.c 2006-09-14 07:07:26.000000000 -0500 +++ policycoreutils-1.30.29.orig.dev/newrole/newrole.c 2006-09-28 14:21:27.000000000 -0500 @@ -47,7 +47,9 @@ * *************************************************************************/ +#ifndef _GNU_SOURCE #define _GNU_SOURCE +#endif I think that the -D_GNU_SOURCE should just be removed from the Makefile. @@ -394,6 +396,41 @@ cap_free(new_caps); } } + +/* Send audit message */ +int send_audit_message(int success, security_context_t old_context, + security_context_t new_context, const char *ttyn) You need to wrap the entire function with #ifdef LOG_AUDIT_PRIV, and provide a trivial inline function in the #else clause, e.g. #else static inline int send_audit_message(int success, security_context_t old_context, security_context_t new_context, const char *ttyn) { return 0; } #endif @@ -536,6 +573,9 @@ if (role_s && !type_s) { if (get_default_type(role_s, &type_s)) { fprintf(stderr, _("Couldn't get default type.\n")); +#ifdef LOG_AUDIT_PRIV + send_audit_message(0, old_context, new_context, ttyn); +#endif You can then drop the #ifdefs here and later, since send_audit_message() will always have a valid definition. -- Stephen Smalley National Security Agency From sgrubb at redhat.com Thu Sep 28 20:15:22 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 28 Sep 2006 16:15:22 -0400 Subject: [redhat-lspp] Re: [PATCH] newrole auditing of failures due to user actions In-Reply-To: <451C2B03.1060300@us.ibm.com> References: <451C2473.7050102@us.ibm.com> <451C2B03.1060300@us.ibm.com> Message-ID: <200609281615.22315.sgrubb@redhat.com> On Thursday 28 September 2006 16:05, Michael C Thompson wrote: > > This patch introduces two new point in the code where audit records are > > generated for newrole. Both points are when the attempt to newrole fails. >From an audit perspective I think it does the right thing. ACK. -Steve From thompsmc at us.ibm.com Thu Sep 28 20:38:55 2006 From: thompsmc at us.ibm.com (Michael C Thompson) Date: Thu, 28 Sep 2006 15:38:55 -0500 Subject: [redhat-lspp] [PATCH] newrole auditing of failures due to user actions In-Reply-To: <1159474257.13831.44.camel@moss-spartans.epoch.ncsc.mil> References: <451C2473.7050102@us.ibm.com> <1159474257.13831.44.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <451C32DF.5000609@us.ibm.com> Stephen Smalley wrote: > On Thu, 2006-09-28 at 14:37 -0500, Michael C Thompson wrote: >> This patch introduces two new point in the code where audit records are >> generated for newrole. Both points are when the attempt to newrole fails. >> >> The first point is when the default type could not be determine for the >> specified role - this is audited because, as sgrubb pointed out, it is >> currently non-tracked path to probe the policy. >> >> The second point is when the desired context to change to is invalid. >> >> There record format remains unchanged. Failing to validate the desired >> context will result in the old and new contexts being recorded intact to >> the log. For the default type, the old and new contexts have not yet >> been obtained, so they are recorded in the log as XXX_context=? >> >> Signed-off-by: Michael Thompson > > (note: needs to go to selinux list if you want it merged) > > --- policycoreutils-1.30.29/newrole/newrole.c 2006-09-14 07:07:26.000000000 -0500 > +++ policycoreutils-1.30.29.orig.dev/newrole/newrole.c 2006-09-28 14:21:27.000000000 -0500 > @@ -47,7 +47,9 @@ > * > *************************************************************************/ > > +#ifndef _GNU_SOURCE > #define _GNU_SOURCE > +#endif > > I think that the -D_GNU_SOURCE should just be removed from the Makefile. Done. > @@ -394,6 +396,41 @@ > cap_free(new_caps); > } > } > + > +/* Send audit message */ > +int send_audit_message(int success, security_context_t old_context, > + security_context_t new_context, const char *ttyn) > > You need to wrap the entire function with #ifdef LOG_AUDIT_PRIV, > and provide a trivial inline function in the #else clause, e.g. > #else > static inline int send_audit_message(int success, security_context_t old_context, > security_context_t new_context, const char *ttyn) > { > return 0; > } > #endif Done. > @@ -536,6 +573,9 @@ > if (role_s && !type_s) { > if (get_default_type(role_s, &type_s)) { > fprintf(stderr, _("Couldn't get default type.\n")); > +#ifdef LOG_AUDIT_PRIV > + send_audit_message(0, old_context, new_context, ttyn); > +#endif > > You can then drop the #ifdefs here and later, since send_audit_message() will always have a valid > definition. Done. Thanks, Mike From paul.moore at hp.com Thu Sep 28 22:44:44 2006 From: paul.moore at hp.com (Paul Moore) Date: Thu, 28 Sep 2006 18:44:44 -0400 Subject: [redhat-lspp] New NetLabel tools package Message-ID: <451C505C.1010400@hp.com> I made a new release (0.17) of the netlabel_tools package to support the recent changes to the NetLabel userspace interface. You can download the latest version here: * http://netlabel.sf.net The netlabelctl tool is still pretty rough, but it's getting better and I hope to be able to dedicate more time to it next week. If you are using the tools and run into any problems or have any feedback please let me know. Also, for those brave souls who dare to look at some ugly user space code, the netlabel_tools package is maintained in the SF.net SVN repository so those of you wishing to stay on the bleeding edge can stay up to date. Thanks. -- paul moore linux security @ hp From ltcgcw at us.ibm.com Fri Sep 29 19:20:20 2006 From: ltcgcw at us.ibm.com (George C. Wilson) Date: Fri, 29 Sep 2006 14:20:20 -0500 Subject: [redhat-lspp] [Reminder] Open LSPP Development Telecon Mon., Oct. 2 Message-ID: <20060929192020.GA3118@us.ibm.com> IBM hosts a telecon every Monday at 20:00 UTC to discuss the development issues surrounding Linux LSPP certification. The call is open to all who have something to bring to the effort. If you would like to participate and are not already an attendee, please reply directly to me with your contact information. I will respond with an invitation. Please note that the number of attendees may be limited by our call center's restrictions on maximum lines per conference. -- George Wilson IBM Linux Technology Center From sgrubb at redhat.com Fri Sep 29 20:30:42 2006 From: sgrubb at redhat.com (Steve Grubb) Date: Fri, 29 Sep 2006 16:30:42 -0400 Subject: [redhat-lspp] lspp 50 kernel released Message-ID: <200609291630.42173.sgrubb@redhat.com> Hi, The lspp.50 kernel has been published to the lspp yum repo at: http://people.redhat.com/sgrubb/files/lspp The changes are: - Fixed audit by ppid - Apply patch for unbounded name_count - Couple new message types - Apply patch to reject any operator except = and != for arch in audit system Please let me know if there any problems with this kernel. -Steve From mra at hp.com Sat Sep 30 03:54:51 2006 From: mra at hp.com (Matt Anderson) Date: Fri, 29 Sep 2006 23:54:51 -0400 Subject: [redhat-lspp] RFC tweak for lpd.if to make it fit CUPS Message-ID: <451DEA8B.2070609@hp.com> I've been playing around with the printing portion of the policy a bit and would like to suggest some changes. Looking at the source for lpd.if it seems the the policy was originally written with a lpr/lpd in mind that is not CUPS. There are comments referencing a lightweight mode, and $1_lpr_t is allowed to read and write to the spool directly. CUPS does not do these things. Attached is a patch I've applied to my systems that allows CUPS to work just fine in Targeted and MLS mode with 13 less allow rules. One side effect of this is that from $1_lpr_t access is no longer given to print_spool_t. If however we were then to allow access for administrators (say: sysadm_r) to print_spool_t we can then use that check to enable lprm and lpq for admins, but still restricting normal users to only seeing their jobs. This eliminates the need for the helper program lspp-access. Do the attached changes make sense? Does the addition of this rule seem reasonable? allow sysadm_lpr_t print_spool_t:file read; Lastly in order to determine if a user is authorized to print to a given printer based on a comparison of their level to that of the printer I'd like to propose this rule: allow $1_lpr_t printer_device_t:file write Thanks -matt -------------- next part -------------- A non-text attachment was scrubbed... Name: cups-policy.patch Type: text/x-patch Size: 2165 bytes Desc: not available URL: From russell at coker.com.au Sat Sep 30 04:23:41 2006 From: russell at coker.com.au (Russell Coker) Date: Sat, 30 Sep 2006 14:23:41 +1000 Subject: [redhat-lspp] Re: RFC tweak for lpd.if to make it fit CUPS In-Reply-To: <451DEA8B.2070609@hp.com> References: <451DEA8B.2070609@hp.com> Message-ID: <200609301423.45245.russell@coker.com.au> On Saturday 30 September 2006 13:54, Matt Anderson wrote: > I've been playing around with the printing portion of the policy a bit > and would like to suggest some changes. Looking at the source for > lpd.if it seems the the policy was originally written with a lpr/lpd in > mind that is not CUPS. Correct. The lpr/lpd policy was written a long time before the cups policy. My recollection is that I wrote the cups policy to support mixed-mode systems with lpr/lpd emulation in CUPS and easy conversion between cups and lpd. For today's use it's probably best to just dump support for lpd. In Fedora cups is the only supported option, for LSPP you have the same but no option of getting lprng from extras, in Debian things are tending towards cups (and with Debian having more support for modules we can probably switch between cups and lpd modules). > There are comments referencing a lightweight > mode, and $1_lpr_t is allowed to read and write to the spool directly. > CUPS does not do these things. Attached is a patch I've applied to my > systems that allows CUPS to work just fine in Targeted and MLS mode with > 13 less allow rules. That seems fine to me. > Does the addition of this rule seem reasonable? > > allow sysadm_lpr_t print_spool_t:file read; Yes. > Lastly in order to determine if a user is authorized to print to a given > printer based on a comparison of their level to that of the printer I'd > like to propose this rule: > > allow $1_lpr_t printer_device_t:file write That's fine, but it will need a clear comment to avoid the risk of having it copied inappropriately in future. -- russell at coker.com.au http://etbe.blogspot.com/ My Blog http://www.coker.com.au/sponsorship.html Sponsoring Free Software development