From Cathleen.Reiher at Sun.COM Fri Aug 1 13:52:04 2008 From: Cathleen.Reiher at Sun.COM (Cathleen Reiher) Date: Fri, 01 Aug 2008 13:52:04 -0700 Subject: [fmac-discuss] Latest FMAC utility man pages posted Message-ID: The FMAC utility man pages for checkpolicy, getenforce, loadpolicy, pcon, setenforce, and setfiles have been posted to the OpenSolaris FMAC project page: http://www.opensolaris.org/os/project/fmac/docs/ These man pages have been updated based on comments from Stephen Smalley. Please review and send your comments to the fmac-discuss list. Cathleen. From sds at tycho.nsa.gov Mon Aug 4 05:57:50 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 04 Aug 2008 08:57:50 -0400 Subject: [fmac-discuss] Latest FMAC utility man pages posted In-Reply-To: References: Message-ID: <1217854670.20067.41.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2008-08-01 at 13:52 -0700, Cathleen Reiher wrote: > The FMAC utility man pages for checkpolicy, > getenforce, loadpolicy, pcon, setenforce, and > setfiles have been posted to the OpenSolaris > FMAC project page: > > http://www.opensolaris.org/os/project/fmac/docs/ > > These man pages have been updated based > on comments from Stephen Smalley. > > Please review and send your comments to > the fmac-discuss list. Won't the source form of these man pages ultimately be added to the fmac source tree somewhere? Where do man pages live in the Solaris source tree? We typically keep the man page sources with the source code for each command in SELinux, which makes it easy to keep them up-to-date. checkpolicy.1m.txt: - "an flexible" => "a flexible" - "into the kernel on the security server" => "into the kernel security server" or just "into the kernel". - "This example shows how to load the binary version.." => "This example shows how to check and debug the binary version..." getenforce.1m.txt: - If you create a general fmac man page, then you can move all of the text here except for discussion of the actual getenforce/setenforce utilities and their usage to that man page and reference it from a SEE ALSO section for all of the FMAC utility man pages. - First sentence seems out of place or lacking a transition to the next one. - You don't explicitly say anywhere that both permissive and enforcing modes will load a policy, perform security labeling, and perform permission checks, and only differ in how they handle permission denials. - Maybe it would be clearer to say that FMAC can be disabled or enabled, and if enabled, it can be permissive or enforcing. Then you can say that as a result, FMAC is always in one of three states, and enumerate them without confusion. - "FMAC only logs unique denial instances" => "In permissive mode, FMAC only logs unique denial instances". - "Source type", "target type" => "Source security context", "Target security context": The type is only one field of the context and denials may be due to other components. The context consists of user:role:type:level. - "for which the access is permitted": in this context, we are talking about denials, so "denied" would make more sense here, or you could just drop this clause entirely and merely define object class as "The kind of object, such as regular file, directory, device node, process, socket, etc". - Setting FMAC properties in the /etc/system File: I'd describe enabled/disabled first, and then enforcing/permissive since the latter depends on the former being enabled. And you should provide the same kind of information, e.g. just as you describe that 1 means enable and 0 means disable for fmac_enabled, you should note that 1 means enforcing and 0 means permissive for fmac_enforcing. The example shown of set fmac_enabled = 1 should be moved to the EXAMPLES section for consistency, and you can also show set fmac_enabled = 0. - In the EXAMPLES section, you might want to also note that setenforce 0 or setenforce 1 can be used in addition to the permissive/enforcing strings. setfiles.1m.txt: - EXAMPLES: mount | awk '{print $3}' doesn't yield the desired output on Solaris. What we want is a listing of the mount points for filesystems that support labeling so that setfiles can walk each such file system in turn and label all of its files. So for example if you have /, /usr, /var, and /export/home partitions and they all support file contexts, then you might run: setfiles /path/to/file_contexts / /usr /var /export/home If we only support labeling on zfs, then you could do the following: setfiles /path/to/file_contexts `mount -p | awk '/zfs/{print $3}'` to apply setfiles to all zfs filesystems. -- Stephen Smalley National Security Agency From Cathleen.Reiher at Sun.COM Wed Aug 6 14:19:46 2008 From: Cathleen.Reiher at Sun.COM (Cathleen Reiher) Date: Wed, 06 Aug 2008 14:19:46 -0700 Subject: [fmac-discuss] Latest FMAC utility man pages posted In-Reply-To: <1217854670.20067.41.camel@moss-spartans.epoch.ncsc.mil> References: <1217854670.20067.41.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Stephen Smalley wrote: > On Fri, 2008-08-01 at 13:52 -0700, Cathleen Reiher wrote: > > The FMAC utility man pages for checkpolicy, > > getenforce, loadpolicy, pcon, setenforce, and > > setfiles have been posted to the OpenSolaris > > FMAC project page: > > > > http://www.opensolaris.org/os/project/fmac/docs/ > > > > These man pages have been updated based > > on comments from Stephen Smalley. > > > > Please review and send your comments to > > the fmac-discuss list. > > Won't the source form of these man pages ultimately be added to the fmac > source tree somewhere? Where do man pages live in the Solaris source > tree? We typically keep the man page sources with the source code for > each command in SELinux, which makes it easy to keep them up-to-date. Thanks for bringing up the issue of the man page sources and how we intend to handle them. Yes, the man page sources will eventually be added to some sort of repository. Right now, the OpenSolaris man page sources are not available in this way. The OpenSolaris docs community needs to determine how to bring these sources to the OpenSolaris community at large. There are issues to address, such as the following: - Will OpenSolaris continue to deliver man pages as a single package (SUNWman), or will man pages be spread throughout the product into the related binary packages instead? Or, will some other plans be devised? - Will the man page sources (currently part of its own consolidation (in usr/src/man)) be made available as a Mercurial repository for us to clone, like we've done with the ONNV source tree? These issues and others must be understood and discussed. I have made some initial inquiries. The FMAC team can discuss how we might want to temporarily handle the storing of man page sources. So far, all the man pages sent out for review are new ones. Our project will probably need to update existing OpenSolaris man pages, as well. The handling existing man pages will be trickier than dealing with new ones. We can do as you described and temporarily place the man page sources with the related source code in our project-specific repository. When the docs community presents the man page source repository, we can clone it as we've done with ONNV, if it makes sense, and move the man page sources to the repository clone. Another possibility is just placing the current man page sources in a tar file that can be downloaded. I could post the tar file on our project page when the man pages change. > checkpolicy.1m.txt: > - "an flexible" => "a flexible" > - "into the kernel on the security server" => "into the kernel security > server" or just "into the kernel". > - "This example shows how to load the binary version.." => "This example > shows how to check and debug the binary version..." Thanks, I've made these changes. > getenforce.1m.txt: > - If you create a general fmac man page, then you can move all of the > text here except for discussion of the actual getenforce/setenforce > utilities and their usage to that man page and reference it from a SEE > ALSO section for all of the FMAC utility man pages. > - First sentence seems out of place or lacking a transition to the next one. > - You don't explicitly say anywhere that both permissive and enforcing > modes will load a policy, perform security labeling, and perform > permission checks, and only differ in how they handle permission denials. > - Maybe it would be clearer to say that FMAC can be disabled or enabled, > and if enabled, it can be permissive or enforcing. Then you can say > that as a result, FMAC is always in one of three states, and enumerate > them without confusion. > - "FMAC only logs unique denial instances" => "In permissive mode, FMAC > only logs unique denial instances". > - "Source type", "target type" => "Source security context", "Target > security context": The type is only one field of the context and > denials may be due to other components. The context consists of > user:role:type:level. > - "for which the access is permitted": in this context, we are talking > about denials, so "denied" would make more sense here, or you could just > drop this clause entirely and merely define object class as "The kind of > object, such as regular file, directory, device node, process, socket, etc". > - Setting FMAC properties in the /etc/system File: I'd describe > enabled/disabled first, and then enforcing/permissive since the latter > depends on the former being enabled. And you should provide the same > kind of information, e.g. just as you describe that 1 means enable and 0 > means disable for fmac_enabled, you should note that 1 means enforcing > and 0 means permissive for fmac_enforcing. The example shown of set > fmac_enabled = 1 should be moved to the EXAMPLES section for > consistency, and you can also show set fmac_enabled = 0. > - In the EXAMPLES section, you might want to also note that setenforce 0 > or setenforce 1 can be used in addition to the permissive/enforcing > strings. I have done as you suggested and created an fmac(5) man page, which includes overview material and pointers to particular FMAC man pages. I've also updated the getenforce(1M) man page. I've posted a strawman of the fmac(5) man page on the project page. Please take a look and let me know what other information should be discussed and what existing information should be clarified and/or corrected. > setfiles.1m.txt: > - EXAMPLES: mount | awk '{print $3}' doesn't yield the desired output > on Solaris. What we want is a listing of the mount points for > filesystems that support labeling so that setfiles can walk each such > file system in turn and label all of its files. So for example if you > have /, /usr, /var, and /export/home partitions and they all support > file contexts, then you might run: > setfiles /path/to/file_contexts / /usr /var /export/home > > If we only support labeling on zfs, then you could do the following: > setfiles /path/to/file_contexts `mount -p | awk '/zfs/{print $3}'` > to apply setfiles to all zfs filesystems. Okay, I've updated this example to include the reference to ZFS that you've added. I've also added the -p option to the mount command. When I try this out, I get no output on my Solaris system, but if I remove the "/zfs/" part of the awk expression, the output lists all of the mounted file systems. Thanks again for the feedback. The updated man pages are posted to the FMAC documentation page. http://www.opensolaris.org/os/project/fmac/docs/ Cathleen. > -- > Stephen Smalley > National Security Agency From Cathleen.Reiher at Sun.COM Tue Aug 12 16:32:58 2008 From: Cathleen.Reiher at Sun.COM (Cathleen Reiher) Date: Tue, 12 Aug 2008 16:32:58 -0700 Subject: [fmac-discuss] FMAC object classes and permissions Message-ID: Hi Team, I've been reading about SELinux object classes and the associated permissions. Will the FMAC project include the same object classes and permissions that are used by SELinux? If not, review the following lists and indicate which object classes and permissions will be used by FMAC. Thanks! Cathleen. The following lists the SELinux object classes described in the book SELinux by Example: - File-Related Object Classes o blk_file o chr_file o dir o fd o fifo_file o file o filesystem o lnk_file o sock_file - Network-Related Object Classes o association o key_socket o netif o netlink_audit_socket o netlink_dnrt_socket o netlink_firewall_socket o netlink_ip6fw_socket o netlink_kobject_uevent_socket o netlink_nflog_socket o netlink_route_socket o netlink_selinux_socket o netlink_socket o netlink_tcpdiag_socket o netlink_xfrm_socket o node o packet_socket o rawip_socket o socket o tcp_socket o udp_socket o unix_dgram_socket o unix_stream_socket - System V IPC Object Classes o ipc (deprecated) o msg o msgq o sem o shm - Miscellaneous Object Classes o capability o process o security o system The following lists the SELinux object class permissions described in the book SELinux by Example: - File Object Class Permissions o append o create o entrypoint o execmod o execute o execute_no_trans o getattr o ioctl o link o lock o mounton o quotaon o read o relabelfrom o relabelto o rename o setattr o swapon o unlink o write - Process Object Class Permissions o dyntransition o execheap o execmem o execstack o fork o getattr o getcap o getpgid o getsched o getsession o noatsecure o ptrace o rlimitnh o setcap o setcurrent o setexec o setfscreate o setpgid o setrlimit o setsched o share o sigchld o siginh o sigkill o signal o signull o sigstop o transition From Cathleen.Reiher at Sun.COM Tue Aug 12 16:37:48 2008 From: Cathleen.Reiher at Sun.COM (Cathleen Reiher) Date: Tue, 12 Aug 2008 16:37:48 -0700 Subject: [fmac-discuss] FMAC to support loadable policy modules? Message-ID: The FMAC utilities does not currently include a checkmodule command. Cathleen. From john.weeks at sun.com Tue Aug 12 16:48:08 2008 From: john.weeks at sun.com (John Weeks) Date: Tue, 12 Aug 2008 16:48:08 -0700 Subject: [fmac-discuss] FMAC object classes and permissions In-Reply-To: References: Message-ID: <48A22138.4090501@sun.com> Cathleen Reiher wrote: > Hi Team, > > I've been reading about SELinux object > classes and the associated permissions. > > Will the FMAC project include the same > object classes and permissions that are > used by SELinux? Because Linux and Solaris provide similar but different system calls, we expect that there will be differences in the object classes and permissions. > > If not, review the following lists and > indicate which object classes and > permissions will be used by FMAC. The current object classes and permissions are defined in usr/src/common/fmac/policy/flask/*. Please note that we are just starting to add policy hooks in the kernel and the object classes and permissions will be modified to match the system calls provided by the Solaris kernel. > > Thanks! > > Cathleen. > > The following lists the SELinux object > classes described in the book SELinux > by Example: > > - File-Related Object Classes > > o blk_file > o chr_file > o dir > o fd > o fifo_file > o file > o filesystem > o lnk_file > o sock_file > > - Network-Related Object Classes > > o association > o key_socket > o netif > o netlink_audit_socket > o netlink_dnrt_socket > o netlink_firewall_socket > o netlink_ip6fw_socket > o netlink_kobject_uevent_socket > o netlink_nflog_socket > o netlink_route_socket > o netlink_selinux_socket > o netlink_socket > o netlink_tcpdiag_socket > o netlink_xfrm_socket > o node > o packet_socket > o rawip_socket > o socket > o tcp_socket > o udp_socket > o unix_dgram_socket > o unix_stream_socket > > - System V IPC Object Classes > > o ipc (deprecated) > o msg > o msgq > o sem > o shm > > - Miscellaneous Object Classes > > o capability > o process > o security > o system > > The following lists the SELinux object > class permissions described in the book > SELinux by Example: > > - File Object Class Permissions > > o append > o create > o entrypoint > o execmod > o execute > o execute_no_trans > o getattr > o ioctl > o link > o lock > o mounton > o quotaon > o read > o relabelfrom > o relabelto > o rename > o setattr > o swapon > o unlink > o write > > - Process Object Class Permissions > > o dyntransition > o execheap > o execmem > o execstack > o fork > o getattr > o getcap > o getpgid > o getsched > o getsession > o noatsecure > o ptrace > o rlimitnh > o setcap > o setcurrent > o setexec > o setfscreate > o setpgid > o setrlimit > o setsched > o share > o sigchld > o siginh > o sigkill > o signal > o signull > o sigstop > o transition > _______________________________________________ > fmac-discuss mailing list > fmac-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/fmac-discuss From john.weeks at sun.com Tue Aug 12 22:40:17 2008 From: john.weeks at sun.com (John Weeks) Date: Tue, 12 Aug 2008 22:40:17 -0700 Subject: [fmac-discuss] [PATCH] pcon should print current context Message-ID: <48A273C1.3010103@sun.com> Pcon should print the current context when no arguments are given. Patch also includes improved error handling and general cleanup. SYNOPSIS /usr/bin/pcon [pid...] EXIT STATUS The following exit values are returned: 0 Successful operation. non-zero An error has occurred. diff --git a/usr/src/cmd/fmac/pcon/pcon.c b/usr/src/cmd/fmac/pcon/pcon.c --- a/usr/src/cmd/fmac/pcon/pcon.c +++ b/usr/src/cmd/fmac/pcon/pcon.c @@ -25,7 +25,7 @@ */ /* - * Display context for specified PIDs + * Display context for current or specified PIDs */ #include @@ -37,42 +37,74 @@ #include #include -static void -show_context(const char *arg) +static char *command; + +static pid_t +str2pid(const char *s) { pid_t pid; - security_context_t context; char *endptr = 0; errno = 0; - pid = strtoul(arg, &endptr, 10); + pid = strtoul(s, &endptr, 10); - if (endptr == arg || *endptr != '\0' || errno || pid < 0) - return; + if (endptr == s || *endptr != '\0' || errno || pid < 0) + return (-1); + else + return (pid); +} - if (getpidcon(pid, &context) == 0) { - (void) printf("%ld: %s\n", pid, context); +static int +show_context(const char *s) +{ + security_context_t context; + pid_t pid; + + if (s == NULL) + pid = getpid(); + else if ((pid = str2pid(s)) == -1) { + (void) fprintf(stderr, gettext("%s: invalid argument: %s\n"), + command, s); + return (1); + } + + if (getpidcon(pid, &context) == -1) { + (void) fprintf(stderr, + gettext("%s: can't get context for %d: %s\n"), + command, (int)pid, strerror(errno)); + return (1); + } else { + (void) printf("%d: %s\n", (int)pid, context); freecon(context); } + + return (0); } int main(int argc, char *argv[]) { + int rc = 0; + (void) setlocale(LC_ALL, ""); #if !defined(TEXT_DOMAIN) /* Should be defined by cc -D */ #define TEXT_DOMAIN "SYS_TEST" /* Use this only if it weren't */ #endif (void) textdomain(TEXT_DOMAIN); + if ((command = strrchr(argv[0], '/')) != NULL) + command++; + else + command = argv[0]; + if (argc <= 1) { - (void) fprintf(stderr, gettext("usage: pcon pid ...\n")); - return (1); + rc += show_context(NULL); + } else { + while (--argc >= 1) { + rc += show_context(*++argv); + } } - while (--argc >= 1) - show_context(*++argv); - - return (0); + return (rc > 255 ? 255 : rc); } From misterniceguy0 at gmail.com Wed Aug 13 03:26:04 2008 From: misterniceguy0 at gmail.com (Mister Nice Guy) Date: Wed, 13 Aug 2008 13:26:04 +0300 Subject: [fmac-discuss] Storesonline, Double Your Promotional Email and Ecommerce Revenue Message-ID: <3b9f447d0808130326j68e335bcoccda4a60f749fd85@mail.gmail.com> *Storesonline, Double Your Promotional Email and Ecommerce Revenue* If you want to be successful in ecommerce, you will have to work harder than just shooting off a newsletter. Check out *Storesonline* for a full ecommerce solution. With just a little bit of effort, you can double the revenue generated from an ecommerce website All it takes is some effort, careful analysis, testing different methods, and then refining them. Make sure you concentrate on building your email list, creating outstanding content for your emails, managing your list, dividing your list into categories and testing. A good home page does not necessarily translate to revenue generation. You should get traffic that converts. *Storesonline* has software that helps you after traffic converts.You have to get new subscribers who visit your website regularly to check out new products or services. This can be done by list building, which in turn is only possible if you expand your current list. Make sure your website has an opt-in subscription form on practically every webpage. Your chances of getting new subscribers will increase if you offer some kind of incentive. An incentive can be anything from an offer for free shipping to giving $20 off on the first order. You can easily get a new customer's email address through the shopping cart form. Make sure you add a link to the subscription form in the transaction confirmation email. This opportunity can be also used to get further details like gender, likes and product interests. These are the tools that *Storesonline*, may offer on their website. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Cathleen.Reiher at Sun.COM Wed Aug 13 11:27:36 2008 From: Cathleen.Reiher at Sun.COM (Cathleen Reiher) Date: Wed, 13 Aug 2008 11:27:36 -0700 Subject: [fmac-discuss] FMAC object classes and permissions In-Reply-To: <48A22138.4090501@sun.com> References: <48A22138.4090501@sun.com> Message-ID: Thanks, John. I'll take a look at the source files. Cathleen. John Weeks wrote: > Cathleen Reiher wrote: > > Hi Team, > > > > I've been reading about SELinux object > > classes and the associated permissions. > > > > Will the FMAC project include the same > > object classes and permissions that are > > used by SELinux? > > Because Linux and Solaris provide similar but different system calls, > we expect that there will be differences in the object classes and permissions. > > > If not, review the following lists and > > indicate which object classes and > > permissions will be used by FMAC. > > The current object classes and permissions are defined in > usr/src/common/fmac/policy/flask/*. Please note that we are just > starting to add policy hooks in the kernel and the object classes and > permissions will be modified to match the system calls provided by the > Solaris kernel. > > > Thanks! > > > > Cathleen. > > > > The following lists the SELinux object > > classes described in the book SELinux > > by Example: > > > > - File-Related Object Classes > > > > o blk_file > > o chr_file > > o dir > > o fd > > o fifo_file > > o file > > o filesystem > > o lnk_file > > o sock_file > > > > - Network-Related Object Classes > > > > o association > > o key_socket > > o netif > > o netlink_audit_socket > > o netlink_dnrt_socket > > o netlink_firewall_socket > > o netlink_ip6fw_socket > > o netlink_kobject_uevent_socket > > o netlink_nflog_socket > > o netlink_route_socket > > o netlink_selinux_socket > > o netlink_socket > > o netlink_tcpdiag_socket > > o netlink_xfrm_socket > > o node > > o packet_socket > > o rawip_socket > > o socket > > o tcp_socket > > o udp_socket > > o unix_dgram_socket > > o unix_stream_socket > > > > - System V IPC Object Classes > > > > o ipc (deprecated) > > o msg > > o msgq > > o sem > > o shm > > > > - Miscellaneous Object Classes > > > > o capability > > o process > > o security > > o system > > > > The following lists the SELinux object > > class permissions described in the book > > SELinux by Example: > > > > - File Object Class Permissions > > > > o append > > o create > > o entrypoint > > o execmod > > o execute > > o execute_no_trans > > o getattr > > o ioctl > > o link > > o lock > > o mounton > > o quotaon > > o read > > o relabelfrom > > o relabelto > > o rename > > o setattr > > o swapon > > o unlink > > o write > > > > - Process Object Class Permissions > > > > o dyntransition > > o execheap > > o execmem > > o execstack > > o fork > > o getattr > > o getcap > > o getpgid > > o getsched > > o getsession > > o noatsecure > > o ptrace > > o rlimitnh > > o setcap > > o setcurrent > > o setexec > > o setfscreate > > o setpgid > > o setrlimit > > o setsched > > o share > > o sigchld > > o siginh > > o sigkill > > o signal > > o signull > > o sigstop > > o transition > > _______________________________________________ > > fmac-discuss mailing list > > fmac-discuss at opensolaris.org > > http://mail.opensolaris.org/mailman/listinfo/fmac-discuss From sds at tycho.nsa.gov Thu Aug 14 11:51:12 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 14 Aug 2008 14:51:12 -0400 Subject: [fmac-discuss] FMAC to support loadable policy modules? In-Reply-To: References: Message-ID: <1218739872.29535.105.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-08-12 at 16:37 -0700, Cathleen Reiher wrote: > The FMAC utilities does not currently > include a checkmodule command. FMAC may eventually support loadable policy modules, although the precise form may differ from the current support in SELinux, which itself is undergoing some re-design. The current FMAC code base predates the policy module support. That support was introduced by a later contribution to SELinux by another party and falls under their copyright and license terms (GPL for utilities, LGPL for libraries). -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Thu Aug 14 11:57:01 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 14 Aug 2008 14:57:01 -0400 Subject: [fmac-discuss] FMAC object classes and permissions In-Reply-To: References: <48A22138.4090501@sun.com> Message-ID: <1218740221.29535.112.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-08-13 at 11:27 -0700, Cathleen Reiher wrote: > Thanks, John. I'll take a look at the > source files. Just to reinforce what John said, I wouldn't draw many conclusions from the current Flask definitions, as they haven't been fitted to the Solaris kernel yet. A more useful exercise for you at this point might be to identify the set of objects in the Solaris kernel that are visible to userspace and the set of operations on those objects provided by the Solaris kernel interfaces. This forms the basis for defining the object classes and permissions. Have a look at the corresponding descriptions of Linux object classes, permissions, and control requirements enumerated in the original SELinux technical report available from: http://www.nsa.gov/selinux/papers/slinux-abs.cfm -- Stephen Smalley National Security Agency From Cathleen.Reiher at Sun.COM Thu Aug 14 12:14:25 2008 From: Cathleen.Reiher at Sun.COM (Cathleen Reiher) Date: Thu, 14 Aug 2008 12:14:25 -0700 Subject: [fmac-discuss] FMAC object classes and permissions In-Reply-To: <1218740221.29535.112.camel@moss-spartans.epoch.ncsc.mil> References: <48A22138.4090501@sun.com> <1218740221.29535.112.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Thanks, Stephen. I'll take a look at this paper you mentioned and see what I can do. Cathleen. Stephen Smalley wrote: > On Wed, 2008-08-13 at 11:27 -0700, Cathleen Reiher wrote: > > Thanks, John. I'll take a look at the > > source files. > > Just to reinforce what John said, I wouldn't draw many conclusions from > the current Flask definitions, as they haven't been fitted to the > Solaris kernel yet. > > A more useful exercise for you at this point might be to identify the > set of objects in the Solaris kernel that are visible to userspace and > the set of operations on those objects provided by the Solaris kernel > interfaces. This forms the basis for defining the object classes and > permissions. > > Have a look at the corresponding descriptions of Linux object classes, > permissions, and control requirements enumerated in the original SELinux > technical report available from: > http://www.nsa.gov/selinux/papers/slinux-abs.cfm > > -- > Stephen Smalley > National Security Agency > From sds at tycho.nsa.gov Thu Aug 14 12:53:06 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 14 Aug 2008 15:53:06 -0400 Subject: [fmac-discuss] Latest FMAC utility man pages posted In-Reply-To: References: <1217854670.20067.41.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1218743586.29535.163.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-08-06 at 14:19 -0700, Cathleen Reiher wrote: > So far, all the man pages sent out for > review are new ones. Our project will > probably need to update existing > OpenSolaris man pages, as well. The > handling existing man pages will be > trickier than dealing with new ones. > > We can do as you described and > temporarily place the man page > sources with the related source code > in our project-specific repository. Yes, that would be my preference - it makes the man page more readily accessible for use and for modification, and it helps keep it in sync with the actual utility. And it means that I can send patches to them instead of just comments ;) > > setfiles.1m.txt: > > - EXAMPLES: mount | awk '{print $3}' doesn't yield the desired output > > on Solaris. What we want is a listing of the mount points for > > filesystems that support labeling so that setfiles can walk each such > > file system in turn and label all of its files. So for example if you > > have /, /usr, /var, and /export/home partitions and they all support > > file contexts, then you might run: > > setfiles /path/to/file_contexts / /usr /var /export/home > > > > If we only support labeling on zfs, then you could do the following: > > setfiles /path/to/file_contexts `mount -p | awk '/zfs/{print $3}'` > > to apply setfiles to all zfs filesystems. > > Okay, I've updated this example to > include the reference to ZFS that > you've added. I've also added the > -p option to the mount command. > > When I try this out, I get no output > on my Solaris system, but if I remove > the "/zfs/" part of the awk expression, > the output lists all of the mounted file > systems. I'm a bit unclear on what you mean by the above. If I run mount -p | awk '/zfs/{print $3}' on a Solaris system here, I see a list of zfs mount points as expected. Note the use of -p though to the mount command; the default mount output in Solaris doesn't give the desired result, unlike in Linux. Or perhaps you just don't have any zfs filesystems on that system? In any event, setfiles won't actually work until we have support for file security contexts in ZFS. > Thanks again for the feedback. > > The updated man pages are posted > to the FMAC documentation page. > > http://www.opensolaris.org/os/project/fmac/docs/ getenforce.1m.txt: - The second sentence of the first para ("When enabled...") isn't necessary as far as I can see. You already cover it in the fmac man page and it isn't dependent on permissive or enforcing mode. - When explaining permissive mode, I think it is clearer to say "operations that _would be_ denied by policy are allowed to proceed". - There is a second difference between permissive and enforcing mode that isn't mentioned here, namely the difference in logging the first instance only of a denial vs. logging each instance of a denial. - The purpose of permissive mode isn't mentioned here and likely should be. - The discussion of fmac_enabled no longer seems to fit in this man page and can be moved to the fmac(5) man page. - If you discuss fmac_enforcing at all here (unclear as to whether it belongs here or in just system(4) and fmac(5)), you likely want to note that it differs from setenforce in that the former is used to set the initial value at boot while the latter can be used to change it during the runtime operation of the system. - typo: configuation. fmac.5.txt: - The first sentence doesn't parse for me. Maybe "FMAC is an implementation of the Flask security architecture for the OpenSolaris (TM) operating system." I'm not sure either whether it ought to be referred to as "OpenSolaris" or "Solaris" when talking about the OS/kernel; presumably you want a single man page that works for both. - 2nd para: More generally, the labeling and the permission checks are used to ensure that the administratively-defined security policy is enforced over all processes and objects based on all security-relevant attributes. The logging isn't really central. - Permissive: I think it is clearer to say "Performs an operation even if it _would be_ denied by policy.". - The discussion of source security context, target, etc is actually independent of enforcing vs. permissive since those elements will be present in any avc denial message. So I'd take that discussion to a separate AVC denial section and just have something like "In permissive mode, FMAC only logs unique AVC denials. See below for discussion of AVC messages." And then I'd actually show an example of an avc message and explain the fields of it. Still have a reference to "source type" and "target type" under Permission. - Security Contexts: A security context is a collection of security attributes rather than an "access control mechanism". It is represented as a string value that may contain multiple fields. The precise format of the string and its meaning is policy-dependent; the example security server provided in SELinux and FMAC happen to use the user:role:type:level format but this can be changed solely by swapping security servers. So it is fine to describe the format but be clear that only the security server and policy-aware applications should be interpreting the context. - FMAC policy file: We typically distinguish between the policy source files (the text files) and the binary policy file that is produced by checkpolicy from those source files. The current description isn't clear that these are two separate files, with one the input for generating the other. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Aug 20 10:43:10 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 20 Aug 2008 13:43:10 -0400 Subject: [fmac-discuss] [PATCH] pcon should print current context In-Reply-To: <48A273C1.3010103@sun.com> References: <48A273C1.3010103@sun.com> Message-ID: <1219254190.30604.32.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2008-08-12 at 22:40 -0700, John Weeks wrote: > Pcon should print the current context when no arguments are given. > > Patch also includes improved error handling and general cleanup. > > SYNOPSIS > /usr/bin/pcon [pid...] > > EXIT STATUS > The following exit values are returned: > > 0 Successful operation. > > non-zero An error has occurred. Acked-by: Stephen Smalley For consistency, we should change fmacsys_getcon() in the kernel to handle pid == curproc->p_pid in the same manner as P_MYID. > > diff --git a/usr/src/cmd/fmac/pcon/pcon.c b/usr/src/cmd/fmac/pcon/pcon.c > --- a/usr/src/cmd/fmac/pcon/pcon.c > +++ b/usr/src/cmd/fmac/pcon/pcon.c > @@ -25,7 +25,7 @@ > */ > > /* > - * Display context for specified PIDs > + * Display context for current or specified PIDs > */ > > #include > @@ -37,42 +37,74 @@ > #include > #include > > -static void > -show_context(const char *arg) > +static char *command; > + > +static pid_t > +str2pid(const char *s) > { > pid_t pid; > - security_context_t context; > char *endptr = 0; > > errno = 0; > > - pid = strtoul(arg, &endptr, 10); > + pid = strtoul(s, &endptr, 10); > > - if (endptr == arg || *endptr != '\0' || errno || pid < 0) > - return; > + if (endptr == s || *endptr != '\0' || errno || pid < 0) > + return (-1); > + else > + return (pid); > +} > > - if (getpidcon(pid, &context) == 0) { > - (void) printf("%ld: %s\n", pid, context); > +static int > +show_context(const char *s) > +{ > + security_context_t context; > + pid_t pid; > + > + if (s == NULL) > + pid = getpid(); > + else if ((pid = str2pid(s)) == -1) { > + (void) fprintf(stderr, gettext("%s: invalid argument: %s\n"), > + command, s); > + return (1); > + } > + > + if (getpidcon(pid, &context) == -1) { > + (void) fprintf(stderr, > + gettext("%s: can't get context for %d: %s\n"), > + command, (int)pid, strerror(errno)); > + return (1); > + } else { > + (void) printf("%d: %s\n", (int)pid, context); > freecon(context); > } > + > + return (0); > } > > int > main(int argc, char *argv[]) > { > + int rc = 0; > + > (void) setlocale(LC_ALL, ""); > #if !defined(TEXT_DOMAIN) /* Should be defined by cc -D */ > #define TEXT_DOMAIN "SYS_TEST" /* Use this only if it weren't */ > #endif > (void) textdomain(TEXT_DOMAIN); > > + if ((command = strrchr(argv[0], '/')) != NULL) > + command++; > + else > + command = argv[0]; > + > if (argc <= 1) { > - (void) fprintf(stderr, gettext("usage: pcon pid ...\n")); > - return (1); > + rc += show_context(NULL); > + } else { > + while (--argc >= 1) { > + rc += show_context(*++argv); > + } > } > > - while (--argc >= 1) > - show_context(*++argv); > - > - return (0); > + return (rc > 255 ? 255 : rc); > } > _______________________________________________ > fmac-discuss mailing list > fmac-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/fmac-discuss -- Stephen Smalley National Security Agency From Cathleen.Reiher at Sun.COM Wed Aug 20 16:32:31 2008 From: Cathleen.Reiher at Sun.COM (Cathleen Reiher) Date: Wed, 20 Aug 2008 16:32:31 -0700 Subject: [fmac-discuss] Latest FMAC utility man pages posted In-Reply-To: <1218743586.29535.163.camel@moss-spartans.epoch.ncsc.mil> References: <1217854670.20067.41.camel@moss-spartans.epoch.ncsc.mil> <1218743586.29535.163.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Stephen Smalley wrote: > On Wed, 2008-08-06 at 14:19 -0700, Cathleen Reiher wrote: > > We can do as you described and > > temporarily place the man page > > sources with the related source code > > in our project-specific repository. > > Yes, that would be my preference - it makes the man page more readily > accessible for use and for modification, and it helps keep it in sync > with the actual utility. And it means that I can send patches to them > instead of just comments ;) Can you tell me more about how the man pages are co-located with the source code for SELinux? Is the man page source file placed into the same directory, say usr/src/cmd/fmac/pcon, or is it placed in a man subdirectory, say usr/src/cmd/fmac/pcon/man? It's easy to see how nice this setup is for utilities. But where, for instance, would the sources for the fmac(5) man page go? Also, how would kernel-related and library-related man pages be stored in the repository? > > > setfiles.1m.txt: > > > - EXAMPLES: mount | awk '{print $3}' doesn't yield the desired output > > > on Solaris. > > I'm a bit unclear on what you mean by the above. I bet that I just don't have any ZFS file systems available and that's why the command line invocation doesn't work for me. No worries. > fmac.5.txt: > AVC Messages section > And then I'd actually show an example of an avc message > and explain the fields of it. Okay, I've added some of the information about the AVC messages that I could find. Will the AVC messages be logged in an FMAC-specific audit log? Or, will they be logged in a general-purpose log, such as the one used by the Solaris auditing system? If these messages will be in an FMAC- specific log, do we really need the type=AVC field? If only AVC messages are logged, they won't need to be identified as such. Or, are other FMAC-related messages logged here, as well? Why don't the comm and name fields include the full path name to the file objects they reference? Wouldn't using full path names be easier than using device IDs and inodes to file the particular file? I'm posting these updated versions of the man pages (getenforce(1M), pcon(1M), and fmac(5)) to the OpenSolaris FMAC project page for further review. I've also added the draft of a new man page, policy.conf(4), which is meant to describe the format of the policy source file(s). It's very sketchy now, so let me know what else should be included in this man page. Cathleen. From sds at tycho.nsa.gov Thu Aug 21 07:05:26 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 21 Aug 2008 10:05:26 -0400 Subject: [fmac-discuss] Latest FMAC utility man pages posted In-Reply-To: References: <1217854670.20067.41.camel@moss-spartans.epoch.ncsc.mil> <1218743586.29535.163.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1219327526.4200.47.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2008-08-20 at 16:32 -0700, Cathleen Reiher wrote: > Stephen Smalley wrote: > > On Wed, 2008-08-06 at 14:19 -0700, Cathleen Reiher wrote: > > > We can do as you described and > > > temporarily place the man page > > > sources with the related source code > > > in our project-specific repository. > > > > Yes, that would be my preference - it makes the man page more readily > > accessible for use and for modification, and it helps keep it in sync > > with the actual utility. And it means that I can send patches to them > > instead of just comments ;) > > Can you tell me more about how the > man pages are co-located with the > source code for SELinux? > > Is the man page source file placed > into the same directory, say > usr/src/cmd/fmac/pcon, or is it > placed in a man subdirectory, say > usr/src/cmd/fmac/pcon/man? For new utilities, we typically put the man page in the same directory as the utility source code unless multiple man pages are required for a single program, in which case a man/ subdirectory might be appropriate. > It's easy to see how nice this setup > is for utilities. But where, for > instance, would the sources for the > fmac(5) man page go? Also, how would > kernel-related and library-related > man pages be stored in the repository? SELinux has a libselinux that defines the interfaces for security-aware applications, and man pages for its interfaces and for general information about selinux go in its libselinux/man subdirectory tree, which is partitioned by manual section number (man3, man5, man8). So far John has placed wrappers for the new FMAC system calls directly into libc in OpenSolaris, so man pages for those would logically go with the libc man pages. However, since those aren't presently available in the source tree anywhere, possibly you could just put general FMAC man pages under a usr/src/common/fmac/man directory tree. > > fmac.5.txt: > > AVC Messages section > > And then I'd actually show an example of an avc message > > and explain the fields of it. > > Okay, I've added some of the information > about the AVC messages that I could > find. I'm guessing you looked at SELinux rather than the actual current FMAC output? The current FMAC output isn't quite the same - it only displays the basic information at present, e.g.: avc: denied { load_policy } for scontext=system_u:system_r:init_t:unclassified tcontext=system_u:object_r:security_t:unclassified tclass=security > Will the AVC messages be logged in an > FMAC-specific audit log? Or, will they > be logged in a general-purpose log, > such as the one used by the Solaris > auditing system? At present they are just using the kernel printf mechanism and hence going to the console and to /var/adm/messages (just like SELinux did originally). Our intent is to rework it to use the Solaris audit facility, just as SELinux now uses the Linux audit subsystem. We may also change the format; there have been complaints about the SELinux format by the Linux audit folks - they would like name=value pairs for all fields and comma-separated lists rather than bracket-delimited lists for the permission set. > If these messages will be in an FMAC- > specific log, do we really need the > type=AVC field? If only AVC messages > are logged, they won't need to be > identified as such. Or, are other > FMAC-related messages logged here, > as well? There is no type= field in the current FMAC output; that is something added by the Linux audit subsystem in the SELinux case. I expect there will be something similar for Solaris though as it will be intermingled with other audit messages. At present the FMAC output is distinguished by the avc: prefix. > Why don't the comm and name fields > include the full path name to the > file objects they reference? Wouldn't > using full path names be easier > than using device IDs and inodes to > file the particular file? Well, those fields don't exist at all presently in the FMAC output. The intent would be to reuse whatever mechanisms presently exist in Solaris audit for collecting auxiliary information like pathnames, device and inode numbers, etc. In the Linux case, we display what information we have readily available at the point of the permission check, which is often at a lower layer that doesn't have full path info, and then the audit subsystem will further display additional information collected during syscall processing upon syscall exit, and those two records can be tied together based on audit event id. So we'll get an exe= and path= record at syscall exit with the full pathnames if syscall auditing is enabled. In any event, that's Linux-specific at present. > I'm posting these updated versions of > the man pages (getenforce(1M), pcon(1M), > and fmac(5)) to the OpenSolaris FMAC > project page for further review. As noted above, the current FMAC avc messages only display the avc: prefix, the denied or granted result (granted will be shown if you have configured auditallow rules to enable auditing of granted permissions in addition to denied ones), the list of permissions, the source context, the target context, and the target security class. The rest of the fields are not implemented for Solaris yet and would likely leverage existing Solaris audit support for recording the pid, path, device & inode, etc. > I've also added the draft of a new man > page, policy.conf(4), which is meant to > describe the format of the policy > source file(s). It's very sketchy now, > so let me know what else should be > included in this man page. You may be able to derive content for this man page from: usr/src/cmd/fmac/policy/README http://www.nsa.gov/selinux/papers/slinux/node15.html http://www.nsa.gov/selinux/papers/policy/policy.html http://www.nsa.gov/selinux/papers/policy2/t1.html You likely want to tell the user where they can find the policy sources in the tree, i.e. usr/src/cmd/fmac/policy, since most users will be editing and building policy from the example policy rather than creating a policy.conf from scratch. At some point we may be able to switch over to using the modern SELinux reference policy, although that is a little unclear at present (requires being able to import GPL'd policy into OpenSolaris). Point of clarification: File contexts configuration is separate from policy.conf, since the former is only read by userland (e.g. setfiles, package manager) in order to set the attributes on files initially, whereas the latter is compiled to kernel policy and loaded into the kernel for runtime use. policy.conf does include some object labeling information though, e.g. defining labels for ports, network interfaces, etc, as those are directly consulted by the kernel. -- Stephen Smalley National Security Agency From john.weeks at sun.com Mon Aug 25 09:01:26 2008 From: john.weeks at sun.com (John Weeks) Date: Mon, 25 Aug 2008 09:01:26 -0700 Subject: [fmac-discuss] [PATCH] Make getpidcon handle pid == curproc->p_pid in the same manner as P_MYID Message-ID: <48B2D756.50605@sun.com> Make fmacsys_getpid() handle curproc->p_pid in the same manner as P_MYID i.e., won't call prfind() for pid of current process. diff --git a/usr/src/uts/common/syscall/fmacsys.c b/usr/src/uts/common/syscall/fmacsys.c --- a/usr/src/uts/common/syscall/fmacsys.c +++ b/usr/src/uts/common/syscall/fmacsys.c @@ -209,7 +209,7 @@ fmacsys_getcon(pid_t pid, security_conte proc_t *p; int err = 0; - if (pid == P_MYID) { + if (pid == P_MYID || pid == curproc->p_pid) { sid = crgetsecid(CRED()); } else { mutex_enter(&pidlock); From sds at tycho.nsa.gov Mon Aug 25 09:05:46 2008 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 25 Aug 2008 12:05:46 -0400 Subject: [fmac-discuss] [PATCH] Make getpidcon handle pid == curproc->p_pid in the same manner as P_MYID In-Reply-To: <48B2D756.50605@sun.com> References: <48B2D756.50605@sun.com> Message-ID: <1219680346.2721.123.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2008-08-25 at 09:01 -0700, John Weeks wrote: > Make fmacsys_getpid() handle curproc->p_pid in the same manner as P_MYID i.e., won't call prfind() for pid of current process. Acked-by: Stephen Smalley > > > diff --git a/usr/src/uts/common/syscall/fmacsys.c b/usr/src/uts/common/syscall/fmacsys.c > --- a/usr/src/uts/common/syscall/fmacsys.c > +++ b/usr/src/uts/common/syscall/fmacsys.c > @@ -209,7 +209,7 @@ fmacsys_getcon(pid_t pid, security_conte > proc_t *p; > int err = 0; > > - if (pid == P_MYID) { > + if (pid == P_MYID || pid == curproc->p_pid) { > sid = crgetsecid(CRED()); > } else { > mutex_enter(&pidlock); > _______________________________________________ > fmac-discuss mailing list > fmac-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/fmac-discuss -- Stephen Smalley National Security Agency From john.weeks at sun.com Thu Aug 28 17:57:58 2008 From: john.weeks at sun.com (John Weeks) Date: Thu, 28 Aug 2008 17:57:58 -0700 Subject: [fmac-discuss] Rebasing fmac-gate to onnv_97 Message-ID: <48B74996.50105@sun.com> Hi, We plan to rebase fmac-gate to onnv_97 very soon (maybe Friday). When we do, we'll send a notice to the list and update the project pages. It will be nice to be current again with onnv :-) Regards, John