Hey all,
So kernel 4.13 was just released which contains the file map stuff and
I've run into a fair few issues. I'd like some discussion about naming
and how to best apply the perm.
we currently have a bunch of interfaces like "*_read_*_files", eg:
files_read_etc_files, files_rw_etc_files, files_manage_etc_files.
should interfaces like this include the map perm? I am thinking no?
Or maybe included for domains that seem to always need it (eg etc_t) and
not by default?
we also have these defs file_read_perms file_mmap_perms. so since those
are different I'm thinking that files_read_etc_files should also be
separated like that?
If they are to be separated, should things be just plain
allow ...:file map; or should it just use file mmap_file_perms;? The
issue with this one is that mmap_file_perms includes the execute perm.
If we should just use mmap_file_perms, then maybe the defs should be
changed like this:
-define(`mmap_file_perms',`{ getattr open map read execute ioctl }')
+define(`mmap_file_perms',`{ getattr open map read ioctl }')
define(`exec_file_perms',`{ getattr open map read execute ioctl execute_no_trans }')
Isnt execute generally a more risky perm? also manage_file_perms and
write_ and rw_ defs currently dont give the map perm, should they?
Once that is decided, what should interfaces for map interfaces look
like? just map? should *_map_*_files interfaces include include read and
open and stuff too ro are people expected to just use both interfaces
together?
########################################
## <summary>
## Map user tmpfs files.
## </summary>
## <param name="domain">
## <summary>
## Domain allowed access.
## </summary>
## </param>
#
interface(`userdom_map_user_tmpfs_files',`
gen_require(`
type user_tmpfs_t;
')
allow $1 user_tmpfs_t:file map;
')
Lastly, Ive seen a whole ton of domains need allow foo etc_t:file map;
and the audit logs show /etc/passwd as the file being accessed. I'm
fairly certain this is from nsswitch. Can someone else verify too?
strace (below) and the fact that there is a very strong correlation with
domains that contain nsswitch_domain.
authlogin.te already contains: files_read_etc_files(nsswitch_domain), so
if we just add file map to the _read_ interfaces then it'll just work.
otherwise adding a files_mmap_etc_files(nsswitch_domain) would work.
excerpt of relevant lines:
$ strace whoami
read(3, "# /etc/nsswitch.conf:\n# $Header:"..., 512) = 508
open("/lib64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
mmap(NULL, 2305, PROT_READ, MAP_SHARED, 3, 0) = 0x7fa04654f000
I'm going to test out these fixes more and will send patches once style
has been decided.
-- Jason
On Sun, Sep 10, 2017 at 08:40:23PM +0800, Jason Zaman via refpolicy wrote:
> Hey all,
>
> So kernel 4.13 was just released which contains the file map stuff and
> I've run into a fair few issues. I'd like some discussion about naming
> and how to best apply the perm.
>
> we currently have a bunch of interfaces like "*_read_*_files", eg:
> files_read_etc_files, files_rw_etc_files, files_manage_etc_files.
> should interfaces like this include the map perm? I am thinking no?
> Or maybe included for domains that seem to always need it (eg etc_t) and
> not by default?
Most of the time you can't really tie the map to the file. one domain might want to map the file, the other might not
the exception are binary files in my opinion. binaries usually get mapped it seems
>
> we also have these defs file_read_perms file_mmap_perms. so since those
> are different I'm thinking that files_read_etc_files should also be
> separated like that?
I would just create a files_map_etc_files() and call that only where needed
>
> If they are to be separated, should things be just plain
> allow ...:file map; or should it just use file mmap_file_perms;? The
> issue with this one is that mmap_file_perms includes the execute perm.
> If we should just use mmap_file_perms, then maybe the defs should be
> changed like this:
>
> -define(`mmap_file_perms',`{ getattr open map read execute ioctl }')
> +define(`mmap_file_perms',`{ getattr open map read ioctl }')
No the mmap_file_perms should be left alone.
a map_file_perms and map_sock_file_perms are probably not worth it (although in dssp2 i did create them)
in other words you should probably just use raw rules
files_map_etc_files(`,'
gen_require(` type etc_t; ')
allow ARG1 etc_t:file map;
')
> define(`exec_file_perms',`{ getattr open map read execute ioctl execute_no_trans }')
>
> Isnt execute generally a more risky perm? also manage_file_perms and
> write_ and rw_ defs currently dont give the map perm, should they?
no because map usually isnt specific to a file (unless its a binary maybe)
one domain might want map on the file and the other might not want map on the file
>
>
> Once that is decided, what should interfaces for map interfaces look
> like? just map? should *_map_*_files interfaces include include read and
> open and stuff too ro are people expected to just use both interfaces
> together?
>
> ########################################
> ## <summary>
> ## Map user tmpfs files.
> ## </summary>
> ## <param name="domain">
> ## <summary>
> ## Domain allowed access.
> ## </summary>
> ## </param>
> #
> interface(`userdom_map_user_tmpfs_files',`
> gen_require(`
> type user_tmpfs_t;
> ')
>
> allow $1 user_tmpfs_t:file map;
> ')
Yes the above looks good to me
>
>
> Lastly, Ive seen a whole ton of domains need allow foo etc_t:file map;
> and the audit logs show /etc/passwd as the file being accessed. I'm
> fairly certain this is from nsswitch. Can someone else verify too?
> strace (below) and the fact that there is a very strong correlation with
> domains that contain nsswitch_domain.
>
> authlogin.te already contains: files_read_etc_files(nsswitch_domain), so
> if we just add file map to the _read_ interfaces then it'll just work.
> otherwise adding a files_mmap_etc_files(nsswitch_domain) would work.
>
> excerpt of relevant lines:
> $ strace whoami
> read(3, "# /etc/nsswitch.conf:\n# $Header:"..., 512) = 508
> open("/lib64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
> open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
> open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
> mmap(NULL, 2305, PROT_READ, MAP_SHARED, 3, 0) = 0x7fa04654f000
>
> I'm going to test out these fixes more and will send patches once style
> has been decided.
for what its worth. i don't allow nss clients to map by default
>
> -- Jason
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170910/805fe1f0/attachment.bin
On Sun, Sep 10, 2017 at 03:45:28PM +0200, Dominick Grift via refpolicy wrote:
> On Sun, Sep 10, 2017 at 08:40:23PM +0800, Jason Zaman via refpolicy wrote:
> > Hey all,
> >
> > So kernel 4.13 was just released which contains the file map stuff and
> > I've run into a fair few issues. I'd like some discussion about naming
> > and how to best apply the perm.
> >
> > we currently have a bunch of interfaces like "*_read_*_files", eg:
> > files_read_etc_files, files_rw_etc_files, files_manage_etc_files.
> > should interfaces like this include the map perm? I am thinking no?
> > Or maybe included for domains that seem to always need it (eg etc_t) and
> > not by default?
>
> Most of the time you can't really tie the map to the file. one domain might want to map the file, the other might not
>
> the exception are binary files in my opinion. binaries usually get mapped it seems
>
> >
> > we also have these defs file_read_perms file_mmap_perms. so since those
> > are different I'm thinking that files_read_etc_files should also be
> > separated like that?
>
> I would just create a files_map_etc_files() and call that only where needed
>
> >
> > If they are to be separated, should things be just plain
> > allow ...:file map; or should it just use file mmap_file_perms;? The
> > issue with this one is that mmap_file_perms includes the execute perm.
> > If we should just use mmap_file_perms, then maybe the defs should be
> > changed like this:
> >
> > -define(`mmap_file_perms',`{ getattr open map read execute ioctl }')
> > +define(`mmap_file_perms',`{ getattr open map read ioctl }')
>
> No the mmap_file_perms should be left alone.
>
> a map_file_perms and map_sock_file_perms are probably not worth it (although in dssp2 i did create them)
>
> in other words you should probably just use raw rules
>
> files_map_etc_files(`,'
> gen_require(` type etc_t; ')
>
> allow ARG1 etc_t:file map;
> ')
okay works for me. one more question then.
files_mmap_etc_files or files_map_etc_files?
> > define(`exec_file_perms',`{ getattr open map read execute ioctl execute_no_trans }')
> >
> > Isnt execute generally a more risky perm? also manage_file_perms and
> > write_ and rw_ defs currently dont give the map perm, should they?
>
> no because map usually isnt specific to a file (unless its a binary maybe)
>
> one domain might want map on the file and the other might not want map on the file
>
> >
> >
> > Once that is decided, what should interfaces for map interfaces look
> > like? just map? should *_map_*_files interfaces include include read and
> > open and stuff too ro are people expected to just use both interfaces
> > together?
> >
> > ########################################
> > ## <summary>
> > ## Map user tmpfs files.
> > ## </summary>
> > ## <param name="domain">
> > ## <summary>
> > ## Domain allowed access.
> > ## </summary>
> > ## </param>
> > #
> > interface(`userdom_map_user_tmpfs_files',`
> > gen_require(`
> > type user_tmpfs_t;
> > ')
> >
> > allow $1 user_tmpfs_t:file map;
> > ')
>
> Yes the above looks good to me
No need for search or anything right? it's assumed some other interface
will handle that?
>
> >
> >
> > Lastly, Ive seen a whole ton of domains need allow foo etc_t:file map;
> > and the audit logs show /etc/passwd as the file being accessed. I'm
> > fairly certain this is from nsswitch. Can someone else verify too?
> > strace (below) and the fact that there is a very strong correlation with
> > domains that contain nsswitch_domain.
> >
> > authlogin.te already contains: files_read_etc_files(nsswitch_domain), so
> > if we just add file map to the _read_ interfaces then it'll just work.
> > otherwise adding a files_mmap_etc_files(nsswitch_domain) would work.
> >
> > excerpt of relevant lines:
> > $ strace whoami
> > read(3, "# /etc/nsswitch.conf:\n# $Header:"..., 512) = 508
> > open("/lib64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
> > open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
> > open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
> > mmap(NULL, 2305, PROT_READ, MAP_SHARED, 3, 0) = 0x7fa04654f000
> >
> > I'm going to test out these fixes more and will send patches once style
> > has been decided.
>
> for what its worth. i don't allow nss clients to map by default
okay thats super weird. I have every single libnss_files doing a mmap
and yours dont... why?
Can someone test on other distros?
-- Jason
On Mon, Sep 11, 2017 at 12:29:51AM +0800, Jason Zaman via refpolicy wrote:
> On Sun, Sep 10, 2017 at 03:45:28PM +0200, Dominick Grift via refpolicy wrote:
> > On Sun, Sep 10, 2017 at 08:40:23PM +0800, Jason Zaman via refpolicy wrote:
> > > Hey all,
> > >
> > > So kernel 4.13 was just released which contains the file map stuff and
> > > I've run into a fair few issues. I'd like some discussion about naming
> > > and how to best apply the perm.
> > >
> > > we currently have a bunch of interfaces like "*_read_*_files", eg:
> > > files_read_etc_files, files_rw_etc_files, files_manage_etc_files.
> > > should interfaces like this include the map perm? I am thinking no?
> > > Or maybe included for domains that seem to always need it (eg etc_t) and
> > > not by default?
> >
> > Most of the time you can't really tie the map to the file. one domain might want to map the file, the other might not
> >
> > the exception are binary files in my opinion. binaries usually get mapped it seems
> >
> > >
> > > we also have these defs file_read_perms file_mmap_perms. so since those
> > > are different I'm thinking that files_read_etc_files should also be
> > > separated like that?
> >
> > I would just create a files_map_etc_files() and call that only where needed
> >
> > >
> > > If they are to be separated, should things be just plain
> > > allow ...:file map; or should it just use file mmap_file_perms;? The
> > > issue with this one is that mmap_file_perms includes the execute perm.
> > > If we should just use mmap_file_perms, then maybe the defs should be
> > > changed like this:
> > >
> > > -define(`mmap_file_perms',`{ getattr open map read execute ioctl }')
> > > +define(`mmap_file_perms',`{ getattr open map read ioctl }')
> >
> > No the mmap_file_perms should be left alone.
> >
> > a map_file_perms and map_sock_file_perms are probably not worth it (although in dssp2 i did create them)
> >
> > in other words you should probably just use raw rules
> >
> > files_map_etc_files(`,'
> > gen_require(` type etc_t; ')
> >
> > allow ARG1 etc_t:file map;
> > ')
>
> okay works for me. one more question then.
> files_mmap_etc_files or files_map_etc_files?
I would go with files_map_etc_files() so that the files_mmap_etc_files() would mean what mmap_file_perms means (not just map but map+exec+read)
>
> > > define(`exec_file_perms',`{ getattr open map read execute ioctl execute_no_trans }')
> > >
> > > Isnt execute generally a more risky perm? also manage_file_perms and
> > > write_ and rw_ defs currently dont give the map perm, should they?
> >
> > no because map usually isnt specific to a file (unless its a binary maybe)
> >
> > one domain might want map on the file and the other might not want map on the file
> >
> > >
> > >
> > > Once that is decided, what should interfaces for map interfaces look
> > > like? just map? should *_map_*_files interfaces include include read and
> > > open and stuff too ro are people expected to just use both interfaces
> > > together?
> > >
> > > ########################################
> > > ## <summary>
> > > ## Map user tmpfs files.
> > > ## </summary>
> > > ## <param name="domain">
> > > ## <summary>
> > > ## Domain allowed access.
> > > ## </summary>
> > > ## </param>
> > > #
> > > interface(`userdom_map_user_tmpfs_files',`
> > > gen_require(`
> > > type user_tmpfs_t;
> > > ')
> > >
> > > allow $1 user_tmpfs_t:file map;
> > > ')
> >
> > Yes the above looks good to me
>
> No need for search or anything right? it's assumed some other interface
> will handle that?
Nope because that would already be covered by other interfaces, a domain never "just maps"
> >
> > >
> > >
> > > Lastly, Ive seen a whole ton of domains need allow foo etc_t:file map;
> > > and the audit logs show /etc/passwd as the file being accessed. I'm
> > > fairly certain this is from nsswitch. Can someone else verify too?
> > > strace (below) and the fact that there is a very strong correlation with
> > > domains that contain nsswitch_domain.
> > >
> > > authlogin.te already contains: files_read_etc_files(nsswitch_domain), so
> > > if we just add file map to the _read_ interfaces then it'll just work.
> > > otherwise adding a files_mmap_etc_files(nsswitch_domain) would work.
> > >
> > > excerpt of relevant lines:
> > > $ strace whoami
> > > read(3, "# /etc/nsswitch.conf:\n# $Header:"..., 512) = 508
> > > open("/lib64/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
> > > open("/lib64/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
> > > open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
> > > mmap(NULL, 2305, PROT_READ, MAP_SHARED, 3, 0) = 0x7fa04654f000
> > >
> > > I'm going to test out these fixes more and will send patches once style
> > > has been decided.
> >
> > for what its worth. i don't allow nss clients to map by default
>
> okay thats super weird. I have every single libnss_files doing a mmap
> and yours dont... why?
Dunno why but if sds would have encountered that as well during his tests he would have added it to his refpolicy patch
then again , he probably did that test on fedora as well
>
> Can someone test on other distros?
>
> -- Jason
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170910/05c8123d/attachment.bin
On Sun, 10 Sep 2017 20:40:23 +0800
Jason Zaman via refpolicy <[email protected]> wrote:
> Lastly, Ive seen a whole ton of domains need allow foo etc_t:file map;
> and the audit logs show /etc/passwd as the file being accessed. I'm
> fairly certain this is from nsswitch. Can someone else verify too?
> strace (below) and the fact that there is a very strong correlation
> with domains that contain nsswitch_domain.
I'm seeing those too, for pretty much all nsswitch domains. Also on
gentoo, with glibc 2.23.
Cheers,
Luis Ressel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170910/80e489a4/attachment-0001.bin
On Sun, 10 Sep 2017 19:22:46 +0200
Luis Ressel via refpolicy <[email protected]> wrote:
> On Sun, 10 Sep 2017 20:40:23 +0800
> Jason Zaman via refpolicy <[email protected]> wrote:
>
> > Lastly, Ive seen a whole ton of domains need allow foo etc_t:file
> > map; and the audit logs show /etc/passwd as the file being
> > accessed. I'm fairly certain this is from nsswitch. Can someone
> > else verify too? strace (below) and the fact that there is a very
> > strong correlation with domains that contain nsswitch_domain.
>
> I'm seeing those too, for pretty much all nsswitch domains. Also on
> gentoo, with glibc 2.23.
I found out why only perfinion and me got these denials: They only
occur when files, group or shadow are set to "compat" mode
in /etc/nsswitch.conf. Unless someone still has a valid usecase for
said compat mode, I'd suggest not adding the map permission here.
Cheers,
Luis Ressel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170911/465845d8/attachment.bin
On Mon, Sep 11, 2017 at 02:15:29AM +0200, Luis Ressel wrote:
> On Sun, 10 Sep 2017 19:22:46 +0200
> Luis Ressel via refpolicy <[email protected]> wrote:
>
> > On Sun, 10 Sep 2017 20:40:23 +0800
> > Jason Zaman via refpolicy <[email protected]> wrote:
> >
> > > Lastly, Ive seen a whole ton of domains need allow foo etc_t:file
> > > map; and the audit logs show /etc/passwd as the file being
> > > accessed. I'm fairly certain this is from nsswitch. Can someone
> > > else verify too? strace (below) and the fact that there is a very
> > > strong correlation with domains that contain nsswitch_domain.
> >
> > I'm seeing those too, for pretty much all nsswitch domains. Also on
> > gentoo, with glibc 2.23.
>
> I found out why only perfinion and me got these denials: They only
> occur when files, group or shadow are set to "compat" mode
> in /etc/nsswitch.conf. Unless someone still has a valid usecase for
> said compat mode, I'd suggest not adding the map permission here.
>
> Cheers,
> Luis Ressel
Nicholas said he has tons of map denials on /etc/passwd too on Arch. at
the very least I think it should be a tunable. if the default config is
map in gentoo i'll almost definitely have to enable it by default
otherwise machines wont even boot before you can set the tunable.
On Mon, 11 Sep 2017 09:01:12 +0800
Jason Zaman via refpolicy <[email protected]> wrote:
> On Mon, Sep 11, 2017 at 02:15:29AM +0200, Luis Ressel wrote:
> > On Sun, 10 Sep 2017 19:22:46 +0200
> > Luis Ressel via refpolicy <[email protected]> wrote:
> >
> > > On Sun, 10 Sep 2017 20:40:23 +0800
> > > Jason Zaman via refpolicy <[email protected]> wrote:
> > >
> > > > Lastly, Ive seen a whole ton of domains need allow foo
> > > > etc_t:file map; and the audit logs show /etc/passwd as the file
> > > > being accessed. I'm fairly certain this is from nsswitch. Can
> > > > someone else verify too? strace (below) and the fact that there
> > > > is a very strong correlation with domains that contain
> > > > nsswitch_domain.
> > >
> > > I'm seeing those too, for pretty much all nsswitch domains. Also
> > > on gentoo, with glibc 2.23.
> >
> > I found out why only perfinion and me got these denials: They only
> > occur when files, group or shadow are set to "compat" mode
> > in /etc/nsswitch.conf. Unless someone still has a valid usecase for
> > said compat mode, I'd suggest not adding the map permission here.
> >
> > Cheers,
> > Luis Ressel
>
> Nicholas said he has tons of map denials on /etc/passwd too on Arch.
> at the very least I think it should be a tunable. if the default
> config is map in gentoo i'll almost definitely have to enable it by
> default otherwise machines wont even boot before you can set the
> tunable.
Actually, I was able to boot and login even when I'd still set nsswitch
to compat mode. I haven't checked the code, but it apparently falls
back to read().
Regards,
Luis Ressel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170911/02870e82/attachment.bin
On 09/10/2017 08:40 AM, Jason Zaman via refpolicy wrote:
> Hey all,
>
> So kernel 4.13 was just released which contains the file map stuff and
> I've run into a fair few issues. I'd like some discussion about naming
> and how to best apply the perm.
>
> we currently have a bunch of interfaces like "*_read_*_files", eg:
> files_read_etc_files, files_rw_etc_files, files_manage_etc_files.
> should interfaces like this include the map perm? I am thinking no?
> Or maybe included for domains that seem to always need it (eg etc_t) and
> not by default?
In general, the map permission should live by itself, especially on
generic types like etc_t. The exception being execs on binaries, as you
have to map to execute a binary.
If you have a specific type who is always associated with mmaping, then
map can be lumped in with other interfaces, for example, lib_t. Using
shared libs requires map and execute.
The main idea being, with mmap, you can mmap read, write, or executable,
so the map permission by itself doesn't tell the whole idea (just like
the open perm). The main danger with map is that it's not revocable, so
once a file is mmaped, if you lose access in the policy (e.g. due to a
boolean change), the mmap isn't revoked.
> we also have these defs file_read_perms file_mmap_perms. so since those
> are different I'm thinking that files_read_etc_files should also be
> separated like that?
>
> If they are to be separated, should things be just plain
> allow ...:file map; or should it just use file mmap_file_perms;? The
> issue with this one is that mmap_file_perms includes the execute perm.
> If we should just use mmap_file_perms, then maybe the defs should be
> changed like this:
>
> -define(`mmap_file_perms',`{ getattr open map read execute ioctl }')
> +define(`mmap_file_perms',`{ getattr open map read ioctl }')
> define(`exec_file_perms',`{ getattr open map read execute ioctl execute_no_trans }')
>
> Isnt execute generally a more risky perm? also manage_file_perms and
> write_ and rw_ defs currently dont give the map perm, should they?
This was an unfortunate mistake with naming, especially now with the map
permission being defined. It is more accurate that the permission set
be "mmap as executable" or "mmap as rx". I'll have to revisit the
permission set usage and the interfaces that use it to come up with a
revised vocabulary for the permission set name(s) and interface verbs.
>
> Once that is decided, what should interfaces for map interfaces look
> like? just map? should *_map_*_files interfaces include include read and
> open and stuff too ro are people expected to just use both interfaces
> together?
>
> ########################################
> ## <summary>
> ## Map user tmpfs files.
> ## </summary>
> ## <param name="domain">
> ## <summary>
> ## Domain allowed access.
> ## </summary>
> ## </param>
> #
> interface(`userdom_map_user_tmpfs_files',`
> gen_require(`
> type user_tmpfs_t;
> ')
>
> allow $1 user_tmpfs_t:file map;
> ')
Yes, this is the general pattern: a map interface + one or more
interfaces to comprise the actual read, write, etc. access.
--
Chris PeBenito
On 09/10/2017 09:31 PM, Luis Ressel via refpolicy wrote:
> On Mon, 11 Sep 2017 09:01:12 +0800
> Jason Zaman via refpolicy <[email protected]> wrote:
>
>> On Mon, Sep 11, 2017 at 02:15:29AM +0200, Luis Ressel wrote:
>>> On Sun, 10 Sep 2017 19:22:46 +0200
>>> Luis Ressel via refpolicy <[email protected]> wrote:
>>>
>>>> On Sun, 10 Sep 2017 20:40:23 +0800
>>>> Jason Zaman via refpolicy <[email protected]> wrote:
>>>>
>>>>> Lastly, Ive seen a whole ton of domains need allow foo
>>>>> etc_t:file map; and the audit logs show /etc/passwd as the file
>>>>> being accessed. I'm fairly certain this is from nsswitch. Can
>>>>> someone else verify too? strace (below) and the fact that there
>>>>> is a very strong correlation with domains that contain
>>>>> nsswitch_domain.
>>>>
>>>> I'm seeing those too, for pretty much all nsswitch domains. Also
>>>> on gentoo, with glibc 2.23.
>>>
>>> I found out why only perfinion and me got these denials: They only
>>> occur when files, group or shadow are set to "compat" mode
>>> in /etc/nsswitch.conf. Unless someone still has a valid usecase for
>>> said compat mode, I'd suggest not adding the map permission here.
>>>
>>> Cheers,
>>> Luis Ressel
>>
>> Nicholas said he has tons of map denials on /etc/passwd too on Arch.
>> at the very least I think it should be a tunable. if the default
>> config is map in gentoo i'll almost definitely have to enable it by
>> default otherwise machines wont even boot before you can set the
>> tunable.
>
> Actually, I was able to boot and login even when I'd still set nsswitch
> to compat mode. I haven't checked the code, but it apparently falls
> back to read().
If that's the case, I'd much rather dontaudit the access, unless there
is some other bad side effect that we don't know of yet.
--
Chris PeBenito
On Mon, Sep 11, 2017 at 08:00:09PM -0400, Chris PeBenito via refpolicy wrote:
> On 09/10/2017 09:31 PM, Luis Ressel via refpolicy wrote:
> > On Mon, 11 Sep 2017 09:01:12 +0800
> > Jason Zaman via refpolicy <[email protected]> wrote:
> >
> >> On Mon, Sep 11, 2017 at 02:15:29AM +0200, Luis Ressel wrote:
> >>> On Sun, 10 Sep 2017 19:22:46 +0200
> >>> Luis Ressel via refpolicy <[email protected]> wrote:
> >>>
> >>>> On Sun, 10 Sep 2017 20:40:23 +0800
> >>>> Jason Zaman via refpolicy <[email protected]> wrote:
> >>>>
> >>>>> Lastly, Ive seen a whole ton of domains need allow foo
> >>>>> etc_t:file map; and the audit logs show /etc/passwd as the file
> >>>>> being accessed. I'm fairly certain this is from nsswitch. Can
> >>>>> someone else verify too? strace (below) and the fact that there
> >>>>> is a very strong correlation with domains that contain
> >>>>> nsswitch_domain.
> >>>>
> >>>> I'm seeing those too, for pretty much all nsswitch domains. Also
> >>>> on gentoo, with glibc 2.23.
> >>>
> >>> I found out why only perfinion and me got these denials: They only
> >>> occur when files, group or shadow are set to "compat" mode
> >>> in /etc/nsswitch.conf. Unless someone still has a valid usecase for
> >>> said compat mode, I'd suggest not adding the map permission here.
> >>>
> >>> Cheers,
> >>> Luis Ressel
> >>
> >> Nicholas said he has tons of map denials on /etc/passwd too on Arch.
> >> at the very least I think it should be a tunable. if the default
> >> config is map in gentoo i'll almost definitely have to enable it by
> >> default otherwise machines wont even boot before you can set the
> >> tunable.
> >
> > Actually, I was able to boot and login even when I'd still set nsswitch
> > to compat mode. I haven't checked the code, but it apparently falls
> > back to read().
>
> If that's the case, I'd much rather dontaudit the access, unless there
> is some other bad side effect that we don't know of yet.
One should consider associating a private type with /etc/passwd /etc/group etc.
If you now associate a dontaudit map etc_t with all nsswitch domain than theres a big chance that domains that need map on other etc_t type associated file breaks and then it wont be so obvious
>
> --
> Chris PeBenito
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170912/d6c501cb/attachment-0001.bin