From john.weeks at sun.com Wed Jun 10 07:55:50 2009 From: john.weeks at sun.com (John Weeks) Date: Wed, 10 Jun 2009 07:55:50 -0700 Subject: [fmac-discuss] Type for utmpx Message-ID: <4A2FC976.7080008@sun.com> While working on the next batch of policy changes, I noticed that the type for /var/adm/utmpx is var_log_t. Should it have its own type like wtmpx (wtmp_t)? -John From Casper.Dik at Sun.COM Wed Jun 10 07:58:54 2009 From: Casper.Dik at Sun.COM (Casper.Dik at Sun.COM) Date: Wed, 10 Jun 2009 16:58:54 +0200 Subject: [fmac-discuss] Type for utmpx In-Reply-To: <4A2FC976.7080008@sun.com> References: <4A2FC976.7080008@sun.com> Message-ID: <200906101458.n5AEwsAp047252@dm-holland-02.uk.sun.com> >While working on the next batch of policy changes, I noticed that the type for /var/adm/utmpx is v ar_log_t. Should it have its own type like wtmpx (wtmp_t)? > utmpx isn't a log file, wtmpx, however, *is* a log file. Casper From sds at tycho.nsa.gov Wed Jun 10 08:12:03 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 10 Jun 2009 11:12:03 -0400 Subject: [fmac-discuss] Type for utmpx In-Reply-To: <4A2FC976.7080008@sun.com> References: <4A2FC976.7080008@sun.com> Message-ID: <1244646723.20265.175.camel@localhost.localdomain> On Wed, 2009-06-10 at 07:55 -0700, John Weeks wrote: > While working on the next batch of policy changes, I noticed that the type for /var/adm/utmpx is var_log_t. Should it have its own type like wtmpx (wtmp_t)? That's because /var/adm is presently being labeled as var_log_t, and utmpx gets re-created on each boot (at least on Linux, don't know for sure about Solaris), so keeping it with a distinct type would require either a type_transition rule in policy (if the creating process runs in its own domain and doesn't create other files under the same parent directory) or the explicit preservation of the security context by the creating process. -- Stephen Smalley National Security Agency From john.weeks at sun.com Wed Jun 10 08:45:44 2009 From: john.weeks at sun.com (John Weeks) Date: Wed, 10 Jun 2009 08:45:44 -0700 Subject: [fmac-discuss] Type for utmpx In-Reply-To: <1244646723.20265.175.camel@localhost.localdomain> References: <4A2FC976.7080008@sun.com> <1244646723.20265.175.camel@localhost.localdomain> Message-ID: <4A2FD528.6080908@sun.com> On 06/10/09 08:12, Stephen Smalley wrote: > On Wed, 2009-06-10 at 07:55 -0700, John Weeks wrote: >> While working on the next batch of policy changes, I noticed that the type for /var/adm/utmpx is var_log_t. Should it have its own type like wtmpx (wtmp_t)? > > That's because /var/adm is presently being labeled as var_log_t, and > utmpx gets re-created on each boot (at least on Linux, don't know for > sure about Solaris), so keeping it with a distinct type would require > either a type_transition rule in policy (if the creating process runs in > its own domain and doesn't create other files under the same parent > directory) or the explicit preservation of the security context by the > creating process. > I've identified two places where the file can be created: usr/src/cmd/svc/startd/utmpx.c ... utmpx_clear_old(void) { int fd; mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH; if (!st->st_initial || utmpx_truncated) return; MUTEX_LOCK(&utmpx_lock); if ((fd = open(_UTMPX_FILE, O_WRONLY | O_CREAT | O_TRUNC, mode)) != -1) { (void) fchmod(fd, mode); /* force mode regardless of umask() */ (void) fchown(fd, 0, 2); /* force owner to root/bin */ (void) close(fd); } else { log_framework(LOG_NOTICE, "Unable to create %s: %s\n", _UTMPX_FILE, strerror(errno)); } utmpx_truncated = 1; MUTEX_UNLOCK(&utmpx_lock); ... or during install: ./SUNWcsr/prototype_com:e preserve var/adm/utmpx 644 root bin Since startd doesn't remove a preexisting utmpx file, should we introduce a specific utmp_t type or just continuing granting var_log_t permissions for domains that require access to utmpx? -John From sds at tycho.nsa.gov Wed Jun 10 08:57:36 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 10 Jun 2009 11:57:36 -0400 Subject: [fmac-discuss] Type for utmpx In-Reply-To: <4A2FD528.6080908@sun.com> References: <4A2FC976.7080008@sun.com> <1244646723.20265.175.camel@localhost.localdomain> <4A2FD528.6080908@sun.com> Message-ID: <1244649456.20265.179.camel@localhost.localdomain> On Wed, 2009-06-10 at 08:45 -0700, John Weeks wrote: > On 06/10/09 08:12, Stephen Smalley wrote: > > On Wed, 2009-06-10 at 07:55 -0700, John Weeks wrote: > >> While working on the next batch of policy changes, I noticed that the type for /var/adm/utmpx is var_log_t. Should it have its own type like wtmpx (wtmp_t)? > > > > That's because /var/adm is presently being labeled as var_log_t, and > > utmpx gets re-created on each boot (at least on Linux, don't know for > > sure about Solaris), so keeping it with a distinct type would require > > either a type_transition rule in policy (if the creating process runs in > > its own domain and doesn't create other files under the same parent > > directory) or the explicit preservation of the security context by the > > creating process. > > > > I've identified two places where the file can be created: > > usr/src/cmd/svc/startd/utmpx.c > > ... > utmpx_clear_old(void) > { > int fd; > mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH; > > if (!st->st_initial || utmpx_truncated) > return; > > MUTEX_LOCK(&utmpx_lock); > > if ((fd = open(_UTMPX_FILE, > O_WRONLY | O_CREAT | O_TRUNC, mode)) != -1) { > (void) fchmod(fd, mode); /* force mode regardless of umask() */ > (void) fchown(fd, 0, 2); /* force owner to root/bin */ > (void) close(fd); > } else { > log_framework(LOG_NOTICE, "Unable to create %s: %s\n", > _UTMPX_FILE, strerror(errno)); > } > > utmpx_truncated = 1; > > MUTEX_UNLOCK(&utmpx_lock); > ... > > or during install: > > ./SUNWcsr/prototype_com:e preserve var/adm/utmpx 644 root bin > > Since startd doesn't remove a preexisting utmpx file, should we introduce a specific utmp_t type or just continuing granting var_log_t permissions for domains that require access to utmpx? A separate type would be preferable. It doesn't necessarily have to be utmp_t; a type is an equivalence class so if there are other files that fit into the same bucket (i.e. the same set of processes/domains will need the same permissions to them), then you could use a more general type name. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Jun 10 09:34:38 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 10 Jun 2009 12:34:38 -0400 Subject: [fmac-discuss] Type for utmpx In-Reply-To: <1244649456.20265.179.camel@localhost.localdomain> References: <4A2FC976.7080008@sun.com> <1244646723.20265.175.camel@localhost.localdomain> <4A2FD528.6080908@sun.com> <1244649456.20265.179.camel@localhost.localdomain> Message-ID: <1244651678.20265.195.camel@localhost.localdomain> On Wed, 2009-06-10 at 11:57 -0400, Stephen Smalley wrote: > On Wed, 2009-06-10 at 08:45 -0700, John Weeks wrote: > > On 06/10/09 08:12, Stephen Smalley wrote: > > > On Wed, 2009-06-10 at 07:55 -0700, John Weeks wrote: > > >> While working on the next batch of policy changes, I noticed that the type for /var/adm/utmpx is var_log_t. Should it have its own type like wtmpx (wtmp_t)? > > > > > > That's because /var/adm is presently being labeled as var_log_t, and > > > utmpx gets re-created on each boot (at least on Linux, don't know for > > > sure about Solaris), so keeping it with a distinct type would require > > > either a type_transition rule in policy (if the creating process runs in > > > its own domain and doesn't create other files under the same parent > > > directory) or the explicit preservation of the security context by the > > > creating process. > > > > > > > I've identified two places where the file can be created: > > > > usr/src/cmd/svc/startd/utmpx.c > > > > ... > > utmpx_clear_old(void) > > { > > int fd; > > mode_t mode = S_IRUSR | S_IWUSR | S_IRGRP | S_IROTH; > > > > if (!st->st_initial || utmpx_truncated) > > return; > > > > MUTEX_LOCK(&utmpx_lock); > > > > if ((fd = open(_UTMPX_FILE, > > O_WRONLY | O_CREAT | O_TRUNC, mode)) != -1) { > > (void) fchmod(fd, mode); /* force mode regardless of umask() */ > > (void) fchown(fd, 0, 2); /* force owner to root/bin */ > > (void) close(fd); > > } else { > > log_framework(LOG_NOTICE, "Unable to create %s: %s\n", > > _UTMPX_FILE, strerror(errno)); > > } > > > > utmpx_truncated = 1; > > > > MUTEX_UNLOCK(&utmpx_lock); > > ... > > > > or during install: > > > > ./SUNWcsr/prototype_com:e preserve var/adm/utmpx 644 root bin > > > > Since startd doesn't remove a preexisting utmpx file, should we introduce a specific utmp_t type or just continuing granting var_log_t permissions for domains that require access to utmpx? > > A separate type would be preferable. It doesn't necessarily have to be > utmp_t; a type is an equivalence class so if there are other files that > fit into the same bucket (i.e. the same set of processes/domains will > need the same permissions to them), then you could use a more general > type name. Actually, I misspoke earlier - Linux also won't remove a pre-existing utmpx file and will thus only truncate it if it is already existing. But as the potential exists for the file to get re-created at boot if it has been removed or moved aside previously, we set up a type transition rule to label it with a type derived from the creating domain and the parent directory type. -- Stephen Smalley National Security Agency From Casper.Dik at Sun.COM Mon Jun 29 05:16:04 2009 From: Casper.Dik at Sun.COM (Casper.Dik at Sun.COM) Date: Mon, 29 Jun 2009 14:16:04 +0200 Subject: [fmac-discuss] Going forward with FMAC in (Open)Solaris In-Reply-To: <1242762191.20082.369.camel@localhost.localdomain> References: <200905191507.n4JF7xmv016941@dm-holland-02.uk.sun.com> <1242762191.20082.369.camel@localhost.localdomain> Message-ID: <200906291216.n5TCG4Hf050191@dm-holland-02.uk.sun.com> >That is certainly possible, but I had some concerns about extending the >secpolicy hooks in that manner when we did the original FMAC >implementation: >- The FMAC hooks need to always be invoked before access is granted, >whereas the existing secpolicy hooks are often only invoked when >privilege is required. I've written a prototype for an implementation of secpolicy_vnode_access() where the secpolicy_vnode_access() is always called whenever an access decision is made. I needed to call it with two different arguments: the access wanted and the mode bits available to the calling process. Where before secpolicy_vnode_access (sva()) is called as followed: mode &= ~allowed_bits; if (mode == 0) return (0); return (sva(cr, vnode, mode) ); it's now called as: return (sva'(cr, vnode, allowed_bits, mode) ); and sva will mask the allowed_bits and it allows hooking the fmac calls: { ... fmac hooks (mode) mode &= ~allowed_bits; if (mode == 0) return (0); /* Rest of the old sva */ I've tested this with two new basic privileges: file_read/file_write, these are defined as: file_read: Allows a process to read a file if DAC permissions allow access. file_write: Allows a process to write a file if DAC permissions allow access. "Basic" privileges are privileges which are assumed to be asserted in the effective set of a non-privileged Solaris process. >- The mapping between operations/code paths and hook calls differs in a >number of cases, e.g. consider the multiple different secpolicy hooks >invoked by zfs_zaccess() vs. the single fmac_vnode_access() call. The zfs_zaccess() function is clearly different from all of the other VFS specific xxx_access() methods. zfs was written after we defined the privilege model for Solaris and that, I think, has it repercussions. I was able to use the same model for zfs_zaccess as the other filesystems, it was just a bit more "work". I believe that FMAC doesn't cater for filesystems other than ZFS, correct? The old code was designed to make privileges as cheap as possible; with FMAC or the basic privileges as defined above require that the secpolicy functions are always called. >- The ideal location for invoking the hook call differs in a number of >cases based on differing inputs and granularity of control. >- I originally hoped to keep more of the FMAC hook calls in the common >vfs layer vs. the filesystem code, although ultimately this proved to be >problematic and many/most of them had to be moved to the filesystem >code. What particular problems did you face when trying to implement the fmac hooks? If there's a problem with the VOP layer, then perhaps that needs to be fixed also. >Many of the FMAC hooks were originally placed in the fop layer and were >later moved into the filesystem code due to problems with hooking at the >fop layer, due not only to insufficient information but also to address >locking concerns and to ensure complete mediation. I think I understand what the problems are there. If I understand correctly, the FMAC prototype in the kernel only adds hooks for files and processes and not for network and others. Which particular hooks are we currently missing? Casper From sds at tycho.nsa.gov Mon Jun 29 07:22:48 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 29 Jun 2009 10:22:48 -0400 Subject: [fmac-discuss] Going forward with FMAC in (Open)Solaris In-Reply-To: <200906291216.n5TCG4Hf050191@dm-holland-02.uk.sun.com> References: <200905191507.n4JF7xmv016941@dm-holland-02.uk.sun.com> <1242762191.20082.369.camel@localhost.localdomain> <200906291216.n5TCG4Hf050191@dm-holland-02.uk.sun.com> Message-ID: <1246285368.5217.75.camel@moss-pluto.epoch.ncsc.mil> On Mon, 2009-06-29 at 14:16 +0200, Casper.Dik at Sun.COM wrote: > >- The mapping between operations/code paths and hook calls differs in a > >number of cases, e.g. consider the multiple different secpolicy hooks > >invoked by zfs_zaccess() vs. the single fmac_vnode_access() call. > > The zfs_zaccess() function is clearly different from all of the other > VFS specific xxx_access() methods. zfs was written after we defined the > privilege model for Solaris and that, I think, has it repercussions. > > I was able to use the same model for zfs_zaccess as the other filesystems, > it was just a bit more "work". I believe that FMAC doesn't cater for > filesystems other than ZFS, correct? Correct - only ZFS (and tmpfs) have been instrumented for FMAC thus far, and the prevailing opinion seemed to be that it wouldn't be worthwhile to retrofit UFS for it, although we're not opposed to that. We'll ultimately need to address devfs/dev and other pseudo filesystems too. In Linux, we have per-file labeling for all of the disk-based native Linux filesystems (via extended attributes), and specialized labeling for various pseudo filesystems (e.g. /proc/pid nodes labeled based on associated process' label, POSIX message queue and UNIX98 pty nodes labeled based on creating process' label). > The old code was designed to make privileges as cheap as possible; > with FMAC or the basic privileges as defined above require that > the secpolicy functions are always called. > > >- The ideal location for invoking the hook call differs in a number of > >cases based on differing inputs and granularity of control. > >- I originally hoped to keep more of the FMAC hook calls in the common > >vfs layer vs. the filesystem code, although ultimately this proved to be > >problematic and many/most of them had to be moved to the filesystem > >code. > > What particular problems did you face when trying to implement the fmac > hooks? If there's a problem with the VOP layer, then perhaps that needs to > be fixed also. http://mail.opensolaris.org/pipermail/fmac-discuss/2008-September/000254.html http://mail.opensolaris.org/pipermail/fmac-discuss/2008-September/000259.html http://mail.opensolaris.org/pipermail/fmac-discuss/2008-September/000262.html http://mail.opensolaris.org/pipermail/fmac-discuss/2008-September/000286.html http://mail.opensolaris.org/pipermail/fmac-discuss/2008-October/000299.html http://mail.opensolaris.org/pipermail/fmac-discuss/2008-October/000309.html http://mail.opensolaris.org/pipermail/fmac-discuss/2008-October/000371.html > >Many of the FMAC hooks were originally placed in the fop layer and were > >later moved into the filesystem code due to problems with hooking at the > >fop layer, due not only to insufficient information but also to address > >locking concerns and to ensure complete mediation. > > I think I understand what the problems are there. > > If I understand correctly, the FMAC prototype in the kernel only > adds hooks for files and processes and not for network and others. > > Which particular hooks are we currently missing? At least a partial list is at: http://www.opensolaris.org/os/project/fmac/ToDoList/ -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Tue Jun 30 07:21:48 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 30 Jun 2009 10:21:48 -0400 Subject: [fmac-discuss] Going forward with FMAC in (Open)Solaris In-Reply-To: <200906291216.n5TCG4Hf050191@dm-holland-02.uk.sun.com> References: <200905191507.n4JF7xmv016941@dm-holland-02.uk.sun.com> <1242762191.20082.369.camel@localhost.localdomain> <200906291216.n5TCG4Hf050191@dm-holland-02.uk.sun.com> Message-ID: <1246371708.13464.94.camel@moss-pluto.epoch.ncsc.mil> On Mon, 2009-06-29 at 14:16 +0200, Casper.Dik at Sun.COM wrote: > >That is certainly possible, but I had some concerns about extending the > >secpolicy hooks in that manner when we did the original FMAC > >implementation: > >- The FMAC hooks need to always be invoked before access is granted, > >whereas the existing secpolicy hooks are often only invoked when > >privilege is required. > > I've written a prototype for an implementation of secpolicy_vnode_access() > where the secpolicy_vnode_access() is always called whenever an access > decision is made. I needed to call it with two different arguments: > the access wanted and the mode bits available to the calling process. > > Where before secpolicy_vnode_access (sva()) is called as followed: > > mode &= ~allowed_bits; > if (mode == 0) > return (0); > > return (sva(cr, vnode, mode) ); > > it's now called as: > > return (sva'(cr, vnode, allowed_bits, mode) ); > > and sva will mask the allowed_bits and it allows hooking the > fmac calls: > > > { > ... fmac hooks (mode) > > > mode &= ~allowed_bits; > if (mode == 0) > return (0); > > /* Rest of the old sva */ > At present, we call fmac_vnode_access() from the tail of zfs_zaccess(), and only call it if the access would otherwise be allowed. That allows us to pass the full ACE mask for finer-grained checking, and it avoids generating spurious FMAC avc denials if the access would have been denied by the base access checking. The fmac_vnode_access() hook implements the FMAC file access checks. Then we call a separate hook, fmac_vnode_priv_access(), from the tail of secpolicy_vnode_access(), and only invoke it if the base privilege logic would deny the access. The fmac_vnode_priv_access() hook implements the FMAC file privilege checks. -- Stephen Smalley National Security Agency From Casper.Dik at Sun.COM Tue Jun 30 07:31:27 2009 From: Casper.Dik at Sun.COM (Casper.Dik at Sun.COM) Date: Tue, 30 Jun 2009 16:31:27 +0200 Subject: [fmac-discuss] Going forward with FMAC in (Open)Solaris In-Reply-To: <1246371708.13464.94.camel@moss-pluto.epoch.ncsc.mil> References: <200905191507.n4JF7xmv016941@dm-holland-02.uk.sun.com> <1242762191.20082.369.camel@localhost.localdomain> <200906291216.n5TCG4Hf050191@dm-holland-02.uk.sun.com> <1246371708.13464.94.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <200906301431.n5UEVR3k024169@dm-holland-02.uk.sun.com> >At present, we call fmac_vnode_access() from the tail of zfs_zaccess(), >and only call it if the access would otherwise be allowed. That allows >us to pass the full ACE mask for finer-grained checking, and it avoids >generating spurious FMAC avc denials if the access would have been >denied by the base access checking. The fmac_vnode_access() hook >implements the FMAC file access checks. > >Then we call a separate hook, fmac_vnode_priv_access(), from the tail of >secpolicy_vnode_access(), and only invoke it if the base privilege logic >would deny the access. The fmac_vnode_priv_access() hook implements the >FMAC file privilege checks. So the actual new sca() code should look like: mode &= ~allowed_bits; if (mode == 0) return (fmac_vnode_access()); /* Standard sva followed by fmac_vnode_priv_access */ Correct? Casper From sds at tycho.nsa.gov Tue Jun 30 07:46:17 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 30 Jun 2009 10:46:17 -0400 Subject: [fmac-discuss] Going forward with FMAC in (Open)Solaris In-Reply-To: <200906301431.n5UEVR3k024169@dm-holland-02.uk.sun.com> References: <200905191507.n4JF7xmv016941@dm-holland-02.uk.sun.com> <1242762191.20082.369.camel@localhost.localdomain> <200906291216.n5TCG4Hf050191@dm-holland-02.uk.sun.com> <1246371708.13464.94.camel@moss-pluto.epoch.ncsc.mil> <200906301431.n5UEVR3k024169@dm-holland-02.uk.sun.com> Message-ID: <1246373177.13464.113.camel@moss-pluto.epoch.ncsc.mil> On Tue, 2009-06-30 at 16:31 +0200, Casper.Dik at Sun.COM wrote: > >At present, we call fmac_vnode_access() from the tail of zfs_zaccess(), > >and only call it if the access would otherwise be allowed. That allows > >us to pass the full ACE mask for finer-grained checking, and it avoids > >generating spurious FMAC avc denials if the access would have been > >denied by the base access checking. The fmac_vnode_access() hook > >implements the FMAC file access checks. > > > >Then we call a separate hook, fmac_vnode_priv_access(), from the tail of > >secpolicy_vnode_access(), and only invoke it if the base privilege logic > >would deny the access. The fmac_vnode_priv_access() hook implements the > >FMAC file privilege checks. > > So the actual new sca() code should look like: > > > > mode &= ~allowed_bits; > if (mode == 0) > return (fmac_vnode_access()); > > > /* Standard sva followed by fmac_vnode_priv_access */ > > > Correct? That doesn't quite match the current logic; at present, fmac_vnode_access() is only invoked if (!mode || ! secpolicy_vnode_access()). Also, we would want to extend the secpolicy_vnode_access() to optionally take an ACE mask, indicated by a flags field, which fmac_vnode_access() already takes. -- Stephen Smalley National Security Agency From Casper.Dik at Sun.COM Tue Jun 30 08:02:10 2009 From: Casper.Dik at Sun.COM (Casper.Dik at Sun.COM) Date: Tue, 30 Jun 2009 17:02:10 +0200 Subject: [fmac-discuss] Going forward with FMAC in (Open)Solaris In-Reply-To: <1246373177.13464.113.camel@moss-pluto.epoch.ncsc.mil> References: <200905191507.n4JF7xmv016941@dm-holland-02.uk.sun.com> <1242762191.20082.369.camel@localhost.localdomain> <200906291216.n5TCG4Hf050191@dm-holland-02.uk.sun.com> <1246371708.13464.94.camel@moss-pluto.epoch.ncsc.mil> <200906301431.n5UEVR3k024169@dm-holland-02.uk.sun.com> <1246373177.13464.113.camel@moss-pluto.epoch.ncsc.mil> Message-ID: <200906301502.n5UF2A1r035279@dm-holland-02.uk.sun.com> >On Tue, 2009-06-30 at 16:31 +0200, Casper.Dik at Sun.COM wrote: >> >At present, we call fmac_vnode_access() from the tail of zfs_zaccess(), >> >and only call it if the access would otherwise be allowed. That allows >> >us to pass the full ACE mask for finer-grained checking, and it avoids >> >generating spurious FMAC avc denials if the access would have been >> >denied by the base access checking. The fmac_vnode_access() hook >> >implements the FMAC file access checks. >> > >> >Then we call a separate hook, fmac_vnode_priv_access(), from the tail of >> >secpolicy_vnode_access(), and only invoke it if the base privilege logic >> >would deny the access. The fmac_vnode_priv_access() hook implements the >> >FMAC file privilege checks. >> >> So the actual new sca() code should look like: >> >> >> >> mode &= ~allowed_bits; >> if (mode == 0) >> return (fmac_vnode_access()); >> >> >> /* Standard sva followed by fmac_vnode_priv_access */ >> >> >> Correct? > >That doesn't quite match the current logic; at present, >fmac_vnode_access() is only invoked if (!mode || ! >secpolicy_vnode_access()). I understand that fmac_vnode_access() is called when all the DAC checks allow access. >Also, we would want to extend the secpolicy_vnode_access() to optionally >take an ACE mask, indicated by a flags field, which fmac_vnode_access() >already takes. Because of ZFS? Or does the FMAC policy makes a distinction between different ACE mask values even when they map to the same vnode permission? (VEXEC/VREAD/VWRITE) Casper From sds at tycho.nsa.gov Tue Jun 30 09:09:36 2009 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 30 Jun 2009 12:09:36 -0400 Subject: [fmac-discuss] Going forward with FMAC in (Open)Solaris In-Reply-To: <200906301502.n5UF2A1r035279@dm-holland-02.uk.sun.com> References: <200905191507.n4JF7xmv016941@dm-holland-02.uk.sun.com> <1242762191.20082.369.camel@localhost.localdomain> <200906291216.n5TCG4Hf050191@dm-holland-02.uk.sun.com> <1246371708.13464.94.camel@moss-pluto.epoch.ncsc.mil> <200906301431.n5UEVR3k024169@dm-holland-02.uk.sun.com> <1246373177.13464.113.camel@moss-pluto.epoch.ncsc.mil> <200906301502.n5UF2A1r035279@dm-holland-02.uk.sun.com> Message-ID: <1246378176.13464.116.camel@moss-pluto.epoch.ncsc.mil> On Tue, 2009-06-30 at 17:02 +0200, Casper.Dik at Sun.COM wrote: > >On Tue, 2009-06-30 at 16:31 +0200, Casper.Dik at Sun.COM wrote: > >> >At present, we call fmac_vnode_access() from the tail of zfs_zaccess(), > >> >and only call it if the access would otherwise be allowed. That allows > >> >us to pass the full ACE mask for finer-grained checking, and it avoids > >> >generating spurious FMAC avc denials if the access would have been > >> >denied by the base access checking. The fmac_vnode_access() hook > >> >implements the FMAC file access checks. > >> > > >> >Then we call a separate hook, fmac_vnode_priv_access(), from the tail of > >> >secpolicy_vnode_access(), and only invoke it if the base privilege logic > >> >would deny the access. The fmac_vnode_priv_access() hook implements the > >> >FMAC file privilege checks. > >> > >> So the actual new sca() code should look like: > >> > >> > >> > >> mode &= ~allowed_bits; > >> if (mode == 0) > >> return (fmac_vnode_access()); > >> > >> > >> /* Standard sva followed by fmac_vnode_priv_access */ > >> > >> > >> Correct? > > > >That doesn't quite match the current logic; at present, > >fmac_vnode_access() is only invoked if (!mode || ! > >secpolicy_vnode_access()). > > I understand that fmac_vnode_access() is called when all the DAC checks > allow access. > > >Also, we would want to extend the secpolicy_vnode_access() to optionally > >take an ACE mask, indicated by a flags field, which fmac_vnode_access() > >already takes. > > Because of ZFS? Or does the FMAC policy makes a distinction between > different ACE mask values even when they map to the same vnode permission? > (VEXEC/VREAD/VWRITE) The latter - FMAC policy supports finer-grained permissions. -- Stephen Smalley National Security Agency