Re: autorelabel loops in system executed 'semodule -d unconfined'
On Tue, Sep 25, 2018 at 07:19:23AM +0900, Shintaro Fujiwara wrote: > Hi, SELinux. > > I captured a picture saying this. > > rm: cannot remove '/.autorelabel' : Permission denied > > /.autorelabel could not be removed, so going into the loop, I guess. > > How can I autorelabel properly even if I delete unconfined module? This may or may not be a policy issue (see avc denials), but: Generally you want to do a full relabel in permissive mode. > > Thanks. > 2018年9月25日(火) 6:55 Shintaro Fujiwara : > > > > Hello, SELinux. > > > > I was playing with my F28 latest with 'semodle -d unconfined'. > > I executed this and relabeling starts even after finished relebeling > > and looks like going into the loop. > > # touch /.autorelabel > > # shtudown -r now > > > > I have attached a picure. > > > > Thanks. > > > > -- > Help analyzing sar file > https://github.com/intrajp/sar-analyzer > > LFS Scripts will make Linux From Scratch easy > https://github.com/intrajp/LFS-scripts-systemd > > SHIRASAGI-hardening Project > https://github.com/intrajp/shirasagi-hardening > > Linux Distribution Project > http://sourceforge.net/projects/pinkrabbitlinux/ > > Introducing hardrock and heavymetal > http://heavymetalhardrock.no-ip.info/ > > Open Source Software to manage SELinux at ease > http://sourceforge.net/projects/segatex/ > > Help SELinux administration > https://github.com/intrajp/segatex-ng > > network-magic ( Useful tool for network-administrators ) > https://github.com/intrajp/network-magic > > CMS（with PHP & PostgreSQL） > http://sourceforge.net/projects/webon/ > https://github.com/intrajp/irforum_jp > ___ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to selinux-le...@tycho.nsa.gov. > To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: MLS dominance check behavior on el7
On Fri, Sep 14, 2018 at 04:18:29PM -0500, Ted Toth wrote:
> On Wed, Sep 12, 2018 at 9:57 AM Ted Toth wrote:
>
> >
> >
> > On Wed, Sep 12, 2018 at 9:36 AM Dominick Grift
> > wrote:
> >
> >> On Wed, Sep 12, 2018 at 09:57:20AM -0400, Stephen Smalley wrote:
> >> > On 09/12/2018 09:26 AM, Ted Toth wrote:
> >> > >
> >> > >
> >> > > On Wed, Sep 12, 2018 at 8:04 AM Stephen Smalley >> > > <mailto:s...@tycho.nsa.gov>> wrote:
> >> > >
> >> > > On 09/11/2018 04:59 PM, Ted Toth wrote:
> >> > > > That's awesome and now it's got me thinking about other
> >> > > > classes/permissions that we could implement. Can cil macros
> >> can be
> >> > > > referenced in .te/.if files?
> >> > >
> >> > > Not sure I understand your question. You can't directly embed cil
> >> > > statements in .te/.if files. However, if you define a
> >> class/permission
> >> > > in a .cil module, you can certainly specify a require on it and
> >> use it
> >> > > from a conventional .te/.if module, ala:
> >> > > $ cat > usemcstrans.te < >> > > policy_module(usemcstrans, 1.0)
> >> > >
> >> > > require {
> >> > > class mcstrans { color_use };
> >> > > attribute domain;
> >> > > }
> >> > >
> >> > > allow domain self:mcstrans color_use;
> >> > > EOF
> >> > >
> >> > > $ make -f /usr/share/selinux/devel/Makefile usemcstrans.pp
> >> > > $ sudo semodule -i usemcstrans.pp
> >> > >
> >> > >
> >> > > If the cil contained:
> >> > >
> >> > > (macro use_color (type caller) (allow caller self mcstrans
> >> (color_use)))
> >> > >
> >> > > then in x.te can I use the macro:
> >> > >
> >> > > type x_t;
> >> > > use_color(x_t)
> >> >
> >> > Sorry, no. The macros used in .te/.if files are just m4 definitions
> >> handled
> >> > at the preprocessing stage, not a feature of the module language. The
> >> CIL
> >> > macros are directly supported by the CIL compiler, but they won't be
> >> visible
> >> > to the module compiler. Also, you are missing several parentheses above
> >> > (I'm not fond of the lisp-like syntax myself). In a CIL module, I
> >> think the
> >> > correct syntax would be:
> >> >
> >> > (macro use_color ((type caller)) (allow caller self (mcstrans
> >> (color_use
> >> >
> >> > (call use_color(x_t))
> >> >
> >> > Or you could define a m4 macro in an .if file and use that in a .te
> >> file.
> >> > Or both.
> >> >
> >>
> >> Ideally you would have all of your policy written in CIL or in a
> >> high-level language that was designed to leverage CIL.
> >>
> >
> > Unfortunately I/we don't live in an ideal world :( but thanks for the
> > pointers.
> >
> >
> >>
> >> My DSSP2 policy is a CIL-only policy. In there I also leverage unordered
> >> classes, Meaning that for example if you remove or disable the mcstrans
> >> module then you automatically also remove or disable the access vectors
> >> that mcstrans manages.
> >>
> >> minimal:
> >>
> >> https://github.com/DefenSec/dssp2-minimal
> >>
> >> standard (my personal policy based on top of minimal):
> >>
> >> https://github.com/DefenSec/dssp2-standard/commits/master
> >>
> >> DSSP2 does not support enforcement of confidentiality though
> >>
> >> > ___
> >> > Selinux mailing list
> >> > Selinux@tycho.nsa.gov
> >> > To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> >> > To get help, send an email containing "help" to
> >> selinux-requ...@tycho.nsa.gov.
> >>
> >> --
> >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> >> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> >> Dominick Grift
> >>
> >
> I added a security class and permission using the following cil:
> (block mcstrans
>
Re: MLS dominance check behavior on el7
On Wed, Sep 12, 2018 at 09:57:20AM -0400, Stephen Smalley wrote:
> On 09/12/2018 09:26 AM, Ted Toth wrote:
> >
> >
> > On Wed, Sep 12, 2018 at 8:04 AM Stephen Smalley > <mailto:s...@tycho.nsa.gov>> wrote:
> >
> > On 09/11/2018 04:59 PM, Ted Toth wrote:
> > > That's awesome and now it's got me thinking about other
> > > classes/permissions that we could implement. Can cil macros can be
> > > referenced in .te/.if files?
> >
> > Not sure I understand your question. You can't directly embed cil
> > statements in .te/.if files. However, if you define a class/permission
> > in a .cil module, you can certainly specify a require on it and use it
> > from a conventional .te/.if module, ala:
> > $ cat > usemcstrans.te < > policy_module(usemcstrans, 1.0)
> >
> > require {
> > class mcstrans { color_use };
> > attribute domain;
> > }
> >
> > allow domain self:mcstrans color_use;
> > EOF
> >
> > $ make -f /usr/share/selinux/devel/Makefile usemcstrans.pp
> > $ sudo semodule -i usemcstrans.pp
> >
> >
> > If the cil contained:
> >
> > (macro use_color (type caller) (allow caller self mcstrans (color_use)))
> >
> > then in x.te can I use the macro:
> >
> > type x_t;
> > use_color(x_t)
>
> Sorry, no. The macros used in .te/.if files are just m4 definitions handled
> at the preprocessing stage, not a feature of the module language. The CIL
> macros are directly supported by the CIL compiler, but they won't be visible
> to the module compiler. Also, you are missing several parentheses above
> (I'm not fond of the lisp-like syntax myself). In a CIL module, I think the
> correct syntax would be:
>
> (macro use_color ((type caller)) (allow caller self (mcstrans (color_use
>
> (call use_color(x_t))
>
> Or you could define a m4 macro in an .if file and use that in a .te file.
> Or both.
>
Ideally you would have all of your policy written in CIL or in a high-level
language that was designed to leverage CIL.
My DSSP2 policy is a CIL-only policy. In there I also leverage unordered
classes, Meaning that for example if you remove or disable the mcstrans module
then you automatically also remove or disable the access vectors that mcstrans
manages.
minimal:
https://github.com/DefenSec/dssp2-minimal
standard (my personal policy based on top of minimal):
https://github.com/DefenSec/dssp2-standard/commits/master
DSSP2 does not support enforcement of confidentiality though
> ___
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: "semanage user" and -s option
On Wed, Sep 05, 2018 at 09:36:35PM +0200, Nicolas Iooss wrote: > Hello, > > While reviewing the last patch sent by Vit Mojzis, I stumbled upon > something that does not feel right in "semanage user". Both "semanage > user --help" and "man 8 semanage-user" state: > > usage: semanage user [-h] [-n] [-N] [-S STORE] [ --add ( -L LEVEL -R > ROLES -r RANGE -s SEUSER selinux_name) | ... > > I am wondering what are the meaning of "-s SEUSER" and "selinux_name" > there. If I try to use "-s" option, semanage complains: > > semanage: error: unrecognized arguments: -s If i recall correctly think "-s selinux_name" is right. You cannot add a seuser withuser giving it a name. > > Therefore it seems that the usage would rather be "... --add ( -L > LEVEL -R ROLES -r RANGE SEUSER)". Looking at the code, it seems that > parser_add_seuser() is not used in setupUserParser() [1], and > everything works fine when using "semanage user" without -s option. Am > I missing something obvious, or should I write a patch which fixes the > documentation? > > Cheers, > Nicolas > > [1] > https://github.com/SELinuxProject/selinux/blob/libsemanage-2.8/python/semanage/semanage#L403 > > ___ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to selinux-le...@tycho.nsa.gov. > To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [refpolicy] map permission in can_exec() but not in domain_transition_pattern()
On Thu, Jul 19, 2018 at 07:54:22PM +0200, Lukas Vrabec via refpolicy wrote:
> On 07/19/2018 07:47 PM, Dominick Grift wrote:
> > On Thu, Jul 19, 2018 at 07:42:53PM +0200, Lukas Vrabec via refpolicy wrote:
> >> On 07/19/2018 06:51 PM, Dominick Grift via refpolicy wrote:
> >>> On Thu, Jul 19, 2018 at 06:40:25PM +0200, Dominick Grift wrote:
> >>>> On Thu, Jul 19, 2018 at 06:17:46PM +0200, Lukas Vrabec via refpolicy
> >>>> wrote:
> >>>>> Hi All,
> >>>>>
> >>>>> I found one thing in refpolicy which I don't completely understand.
> >>>>>
> >>>>> In "policy/support/misc_patterns.spt" there is definition of
> >>>>> "domain_transition_pattern" and this contains line:
> >>>>> allow $1 $2:file { getattr open read execute };
> >>>>>
> >>>>> There is missing map permission.
> >>>>>
> >>>>> However in "policy/support/misc_macros.spt" there is definition of
> >>>>> "can_exec" and it contains allow rule:
> >>>>> define(`can_exec',`allow $1 $2:file { mmap_exec_file_perms ioctl lock
> >>>>> execute_no_trans };')
> >>>
> >>> Sorry can_exec() should just use exec_file_perms which would should be
> >>> mmap_exec_file_perms + execute_no_trans IMHO
> >>>
> >>>>
> >>>> This should just use mmap_exec_file_perms
> >>>>
> >>
> >> Should we remove lock permission?
> >
> > I would say yes, but i am not sure why it was added in the first place
> >
>
> It could be dangerous to remove it in such general macro. Let's test it
> before.
You might also just add it to mmap_exec_file_perms, even though i do not
believe that either mmap_exec_file_perms or exec_file_perms need it, its not
such a big deal.
>
> >>
> >>>>>
> >>>>> There is a mmap_exec_file_perms which contains:
> >>>>> define(`mmap_exec_file_perms',`{ getattr open map read execute ioctl }')
> >>>>>
> >>>>> Map is present in can_exec().
> >>>>>
> >>>>> So for domain transitions we don't allow map permission from calling
> >>>>> domain on binary type but in can_exec macro there is map permission.
> >>>>>
> >>>>> I think this is a bug and in "domain_transition_pattern" there should be
> >>>>> this line:
> >>>>> allow $1 $2:file { getattr open read execute map };
> >>>>
> >>>> This should just use mmap_exec_file_perms as well
> >>>>
> >>>>>
> >>>>> instead of:
> >>>>> allow $1 $2:file { getattr open read execute };
> >>>>>
> >>>>> Am I right or missing something?
> >>>>>
> >>>>> Thanks for help!
> >>>>> Lukas.
> >>>>
> >>>> permission sets provide a single point of failure and should used as
> >>>> much as possible
> >>>>
> >>>> These were overlooked and because of this we now have a good example
> >>>> what the purpose of permission sets and patterns is.
> >>>>
> >>
> >> Thanks, I'll prepare patch.
> >>
> >> Lukas.
> >>
> >>>>>
> >>>>> --
> >>>>> Lukas Vrabec
> >>>>> Software Engineer, Security Technologies
> >>>>> Red Hat, Inc.
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> ___
> >>>>> refpolicy mailing list
> >>>>> refpol...@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=0x3B6C5F1D2C7B6B02
> >>>> Dominick Grift
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> ___
> >>> refpolicy mailing list
> >>> refpol...@oss.tresys.com
> >>> http://oss.tresys.com/mailman/listinfo/refpolicy
> >>>
> >>
> >>
> >> --
> >> Lukas Vrabec
> >> Software Engineer, Security Technologies
> >> Red Hat, Inc.
> >>
> >
> >
> >
> >
> >> ___
> >> refpolicy mailing list
> >> refpol...@oss.tresys.com
> >> http://oss.tresys.com/mailman/listinfo/refpolicy
> >
> >
> >
> >
> > ___
> > Selinux mailing list
> > Selinux@tycho.nsa.gov
> > To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
> > To get help, send an email containing "help" to
> > selinux-requ...@tycho.nsa.gov.
> >
>
>
> --
> Lukas Vrabec
> Software Engineer, Security Technologies
> Red Hat, Inc.
>
> ___
> refpolicy mailing list
> refpol...@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=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [refpolicy] map permission in can_exec() but not in domain_transition_pattern()
On Thu, Jul 19, 2018 at 07:42:53PM +0200, Lukas Vrabec via refpolicy wrote:
> On 07/19/2018 06:51 PM, Dominick Grift via refpolicy wrote:
> > On Thu, Jul 19, 2018 at 06:40:25PM +0200, Dominick Grift wrote:
> >> On Thu, Jul 19, 2018 at 06:17:46PM +0200, Lukas Vrabec via refpolicy wrote:
> >>> Hi All,
> >>>
> >>> I found one thing in refpolicy which I don't completely understand.
> >>>
> >>> In "policy/support/misc_patterns.spt" there is definition of
> >>> "domain_transition_pattern" and this contains line:
> >>> allow $1 $2:file { getattr open read execute };
> >>>
> >>> There is missing map permission.
> >>>
> >>> However in "policy/support/misc_macros.spt" there is definition of
> >>> "can_exec" and it contains allow rule:
> >>> define(`can_exec',`allow $1 $2:file { mmap_exec_file_perms ioctl lock
> >>> execute_no_trans };')
> >
> > Sorry can_exec() should just use exec_file_perms which would should be
> > mmap_exec_file_perms + execute_no_trans IMHO
> >
> >>
> >> This should just use mmap_exec_file_perms
> >>
>
> Should we remove lock permission?
I would say yes, but i am not sure why it was added in the first place
>
> >>>
> >>> There is a mmap_exec_file_perms which contains:
> >>> define(`mmap_exec_file_perms',`{ getattr open map read execute ioctl }')
> >>>
> >>> Map is present in can_exec().
> >>>
> >>> So for domain transitions we don't allow map permission from calling
> >>> domain on binary type but in can_exec macro there is map permission.
> >>>
> >>> I think this is a bug and in "domain_transition_pattern" there should be
> >>> this line:
> >>> allow $1 $2:file { getattr open read execute map };
> >>
> >> This should just use mmap_exec_file_perms as well
> >>
> >>>
> >>> instead of:
> >>> allow $1 $2:file { getattr open read execute };
> >>>
> >>> Am I right or missing something?
> >>>
> >>> Thanks for help!
> >>> Lukas.
> >>
> >> permission sets provide a single point of failure and should used as much
> >> as possible
> >>
> >> These were overlooked and because of this we now have a good example what
> >> the purpose of permission sets and patterns is.
> >>
>
> Thanks, I'll prepare patch.
>
> Lukas.
>
> >>>
> >>> --
> >>> Lukas Vrabec
> >>> Software Engineer, Security Technologies
> >>> Red Hat, Inc.
> >>>
> >>
> >>
> >>
> >>
> >>> ___
> >>> refpolicy mailing list
> >>> refpol...@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=0x3B6C5F1D2C7B6B02
> >> Dominick Grift
> >
> >
> >
> >
> >
> > ___
> > refpolicy mailing list
> > refpol...@oss.tresys.com
> > http://oss.tresys.com/mailman/listinfo/refpolicy
> >
>
>
> --
> Lukas Vrabec
> Software Engineer, Security Technologies
> Red Hat, Inc.
>
> ___
> refpolicy mailing list
> refpol...@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=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [refpolicy] map permission in can_exec() but not in domain_transition_pattern()
On Thu, Jul 19, 2018 at 06:40:25PM +0200, Dominick Grift wrote:
> On Thu, Jul 19, 2018 at 06:17:46PM +0200, Lukas Vrabec via refpolicy wrote:
> > Hi All,
> >
> > I found one thing in refpolicy which I don't completely understand.
> >
> > In "policy/support/misc_patterns.spt" there is definition of
> > "domain_transition_pattern" and this contains line:
> > allow $1 $2:file { getattr open read execute };
> >
> > There is missing map permission.
> >
> > However in "policy/support/misc_macros.spt" there is definition of
> > "can_exec" and it contains allow rule:
> > define(`can_exec',`allow $1 $2:file { mmap_exec_file_perms ioctl lock
> > execute_no_trans };')
Sorry can_exec() should just use exec_file_perms which would should be
mmap_exec_file_perms + execute_no_trans IMHO
>
> This should just use mmap_exec_file_perms
>
> >
> > There is a mmap_exec_file_perms which contains:
> > define(`mmap_exec_file_perms',`{ getattr open map read execute ioctl }')
> >
> > Map is present in can_exec().
> >
> > So for domain transitions we don't allow map permission from calling
> > domain on binary type but in can_exec macro there is map permission.
> >
> > I think this is a bug and in "domain_transition_pattern" there should be
> > this line:
> > allow $1 $2:file { getattr open read execute map };
>
> This should just use mmap_exec_file_perms as well
>
> >
> > instead of:
> > allow $1 $2:file { getattr open read execute };
> >
> > Am I right or missing something?
> >
> > Thanks for help!
> > Lukas.
>
> permission sets provide a single point of failure and should used as much as
> possible
>
> These were overlooked and because of this we now have a good example what the
> purpose of permission sets and patterns is.
>
> >
> > --
> > Lukas Vrabec
> > Software Engineer, Security Technologies
> > Red Hat, Inc.
> >
>
>
>
>
> > ___
> > refpolicy mailing list
> > refpol...@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=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: [refpolicy] map permission in can_exec() but not in domain_transition_pattern()
On Thu, Jul 19, 2018 at 06:17:46PM +0200, Lukas Vrabec via refpolicy wrote:
> Hi All,
>
> I found one thing in refpolicy which I don't completely understand.
>
> In "policy/support/misc_patterns.spt" there is definition of
> "domain_transition_pattern" and this contains line:
> allow $1 $2:file { getattr open read execute };
>
> There is missing map permission.
>
> However in "policy/support/misc_macros.spt" there is definition of
> "can_exec" and it contains allow rule:
> define(`can_exec',`allow $1 $2:file { mmap_exec_file_perms ioctl lock
> execute_no_trans };')
This should just use mmap_exec_file_perms
>
> There is a mmap_exec_file_perms which contains:
> define(`mmap_exec_file_perms',`{ getattr open map read execute ioctl }')
>
> Map is present in can_exec().
>
> So for domain transitions we don't allow map permission from calling
> domain on binary type but in can_exec macro there is map permission.
>
> I think this is a bug and in "domain_transition_pattern" there should be
> this line:
> allow $1 $2:file { getattr open read execute map };
This should just use mmap_exec_file_perms as well
>
> instead of:
> allow $1 $2:file { getattr open read execute };
>
> Am I right or missing something?
>
> Thanks for help!
> Lukas.
permission sets provide a single point of failure and should used as much as
possible
These were overlooked and because of this we now have a good example what the
purpose of permission sets and patterns is.
>
> --
> Lukas Vrabec
> Software Engineer, Security Technologies
> Red Hat, Inc.
>
> ___
> refpolicy mailing list
> refpol...@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=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
___
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: Invalid security context while executing audit2alllow.orig
On Tue, May 29, 2018 at 05:09:53PM +0530, bhawna goel wrote: > Hi Team, > > We are getting below error while creating policies using command > audit2allow.orig. Can you help in identifying what could be the possible > reason of such error. The context "specialuser_u:system_r:ssh_t:s0" is invalid. Either "specialuser_u" is not authorized to associate with "system_r" role, or the system_r role is not allowed to associate with "ssh_t" type. seinfo -xuspecialuser_u | grep system_r seinfo -xrsystem_r | grep ssh_t > > Error: > libsepol.context_from_record: invalid security context: > "specialuser_u:system_r:ssh_t:s0" > libsepol.context_from_record: could not create context structure > libsepol.context_from_string: could not create context structure > libsepol.sepol_context_to_sid: could not convert > specialuser_u:system_r:ssh_t:s0 to sid > > Thanks in Advance > > Regards, > Bhawna > ___ > Selinux mailing list > Selinux@tycho.nsa.gov > To unsubscribe, send email to selinux-le...@tycho.nsa.gov. > To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature ___ Selinux mailing list Selinux@tycho.nsa.gov To unsubscribe, send email to selinux-le...@tycho.nsa.gov. To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.
Re: Last call for selinux userspace 2.8 release
On Fri, May 04, 2018 at 09:36:12AM -0400, Stephen Smalley wrote: > On 05/04/2018 09:26 AM, Dominick Grift wrote: > > On Fri, May 04, 2018 at 09:08:36AM -0400, Stephen Smalley wrote: > >> On 05/04/2018 03:55 AM, Jason Zaman wrote: > >>> On Thu, May 03, 2018 at 10:52:24AM -0400, Stephen Smalley wrote: > >>>> Hi, > >>>> > >>>> If you have encountered any unreported problems with the 2.8-rcX > >>>> releases or have any > >>>> pending patches you believe should be included in the 2.8 release, > >>>> please post them soon. > >>> > >>> the rc2 release has been fine for me for several days now. And I havent > >>> heard any issues from any gentoo users either so we're probably good to > >>> go. -rc1 failed to boot properly for me because some important things in > >>> /run or /dev didnt get labeled but that was fixed in rc2. > >> > >> Hmm...I'd like to understand that better. The change was verifying > >> file_contexts when using restorecon, > >> which was reverted in -rc2. But the fact that it prevented labeling files > >> in -rc1 means that either > >> you have a bug in your file_contexts configuration or there is some other > >> bug there. > > > > If it cannot validate_context then it will be unhappy: > > > > [root@julius ~]# dnf history info last > > Transaction ID : 364 > > Begin time : Fri 04 May 2018 01:12:36 PM CEST > > Begin rpmdb: 1404:e739a03c49fec80ed41a1ea4c599d8f877b01d76 > > End time : Fri 04 May 2018 01:14:01 PM CEST (85 seconds) > > End rpmdb : 1404:27bd40dce7edbf226ffad80f482cd75231f1b6ab ** > > User : kcinimod > > Return-Code: Success > > Command Line : update --exclude efi-filesystem > > Transaction performed with: > > Installed dnf-2.7.5-12.fc29.noarch @rawhide > > Installed rpm-4.14.1-8.fc28.x86_64 @tmp-rawhide > > Packages Altered: > > Upgraded cockpit-166-1.fc29.x86_64 @rawhide > > ... snip ... > > Scriptlet output: > >1 restorecon: /etc/selinux/dssp2-standard/contexts/files/file_contexts: > > has invalid context sys.id:sys.role:files.generic_boot.boot_file:s0 > > 2 restorecon: > > /etc/selinux/dssp2-standard/contexts/files/file_contexts: has invalid > > context sys.id:sys.role:files.generic_boot.boot_file:s0 > > 3 restorecon: > > /etc/selinux/dssp2-standard/contexts/files/file_contexts: has invalid > > context sys.id:sys.role:files.generic_boot.boot_file:s0 > > 4 restorecon: > > /etc/selinux/dssp2-standard/contexts/files/file_contexts: has invalid > > context sys.id:sys.role:files.generic_boot.boot_file:s0 > >5 restorecon: > > /etc/selinux/dssp2-standard/contexts/files/file_contexts: has invalid > > context sys.id:sys.role:files.generic_boot.boot_file:s0 > > So, just to be clear: these contexts are in fact valid but the lack of > permission to use the /sys/fs/selinux/context interface (for > security_check_context) causes it to think the context is invalid and > therefore fails? If so, then > that makes sense and would be another reason for reverting that change. In > any case, -rc2 should have the fix. Yes contexts are valid but since validate_context was blocked this happened. By allowing validate_context this works fine -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: Last call for selinux userspace 2.8 release
, etc.,
> >> DESTDIR has to be removed from the definition. For example on Arch
> >> Linux, SBINDIR="${pkgdir}/usr/bin" was changed to SBINDIR="/usr/bin".
> >>
> >> * Defining variable LIBSEPOLA (to /usr/lib/libsepol.a, for example) is
> >> no longer mandatory (thanks to the switch to "-l:libsepol.a" in
> >> Makefiles).
> >>
> >> * PYSITEDIR has been renamed PYTHONLIBDIR (and its definition changed).
> >>
> >> * selinux-gui (i.e. system-config-selinux GUI application) is now
> >> compatible with Python 3. Doing this required migrating away from
> >> PyGTK to the supported PyGI library. This means that selinux-gui now
> >> depends on python-gobject, Gtk+ 3 and selinux-python. It no longer
> >> requires PyGtk or Python 2.
> >
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: Last call for selinux userspace 2.8 release
On Fri, May 04, 2018 at 09:09:20AM -0400, Stephen Smalley wrote:
> On 05/04/2018 08:19 AM, Dominick Grift wrote:
> > On Thu, May 03, 2018 at 10:52:24AM -0400, Stephen Smalley wrote:
> >> Hi,
> >>
> >> If you have encountered any unreported problems with the 2.8-rcX releases
> >> or have any
> >> pending patches you believe should be included in the 2.8 release, please
> >> post them soon.
> >> Also, let us know of any additions or changes that should be made to the
> >> release notes;
> >> the current draft is as follows.
> >>
> >> User-visible changes:
> >
> > One might see processes "validate_context" where they didnt before
> >
> > Generally processes that use lgetfilecon/lsetfilecon i suspect (like lvm,
> > various systemd components etc)
>
> That should no longer be true as of -rc2 since I reverted the libselinux:
> verify file_contexts when using restorecon change.
Oh thanks, yes fedora is still on RC1.
>
> >
> >>
> >> * semanage fcontext -l now also lists home directory entries from
> >> file_contexts.homedirs.
> >>
> >> * semodule can now enable or disable multiple modules in the same
> >> operation by specifying a list of modules after -e or -d, making them
> >> consistent with the -i/u/r/E options.
> >>
> >> * CIL now supports multiple declarations of types, attributes, and
> >> (non-conflicting) object contexts (e.g. genfscon), enabled via the -m
> >> or --multiple-decls option to secilc.
> >>
> >> * libsemanage no longer deletes the tmp directory if there is an error
> >> while committing the policy transaction, so that any temporary files
> >> can be further inspected for debugging purposes (e.g. to examine a
> >> particular line of the generated CIL module). The tmp directory will
> >> be deleted upon the next transaction, so no manual removal is needed.
> >>
> >> * Support was added for SCTP portcon statements. The corresponding
> >> kernel support was introduced in Linux 4.17, and is only active if the
> >> extended_socket_class policy capability is enabled in the policy.
> >>
> >> * sepol_polcap_getnum/name() were exported as part of the shared libsepol
> >> interface, initially for use by setools4.
> >>
> >> * semodule_deps was removed since it has long been broken and is not useful
> >> for CIL modules.
> >>
> >> Packaging-relevant changes:
> >>
> >> * When overriding PREFIX, BINDIR, SBINDIR, SHLIBDIR, LIBEXECDIR, etc.,
> >> DESTDIR has to be removed from the definition. For example on Arch
> >> Linux, SBINDIR="${pkgdir}/usr/bin" was changed to SBINDIR="/usr/bin".
> >>
> >> * Defining variable LIBSEPOLA (to /usr/lib/libsepol.a, for example) is
> >> no longer mandatory (thanks to the switch to "-l:libsepol.a" in
> >> Makefiles).
> >>
> >> * PYSITEDIR has been renamed PYTHONLIBDIR (and its definition changed).
> >>
> >> * selinux-gui (i.e. system-config-selinux GUI application) is now
> >> compatible with Python 3. Doing this required migrating away from
> >> PyGTK to the supported PyGI library. This means that selinux-gui now
> >> depends on python-gobject, Gtk+ 3 and selinux-python. It no longer
> >> requires PyGtk or Python 2.
> >
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: Last call for selinux userspace 2.8 release
On Thu, May 03, 2018 at 10:52:24AM -0400, Stephen Smalley wrote:
> Hi,
>
> If you have encountered any unreported problems with the 2.8-rcX releases or
> have any
> pending patches you believe should be included in the 2.8 release, please
> post them soon.
> Also, let us know of any additions or changes that should be made to the
> release notes;
> the current draft is as follows.
>
> User-visible changes:
One might see processes "validate_context" where they didnt before
Generally processes that use lgetfilecon/lsetfilecon i suspect (like lvm,
various systemd components etc)
>
> * semanage fcontext -l now also lists home directory entries from
> file_contexts.homedirs.
>
> * semodule can now enable or disable multiple modules in the same
> operation by specifying a list of modules after -e or -d, making them
> consistent with the -i/u/r/E options.
>
> * CIL now supports multiple declarations of types, attributes, and
> (non-conflicting) object contexts (e.g. genfscon), enabled via the -m
> or --multiple-decls option to secilc.
>
> * libsemanage no longer deletes the tmp directory if there is an error
> while committing the policy transaction, so that any temporary files
> can be further inspected for debugging purposes (e.g. to examine a
> particular line of the generated CIL module). The tmp directory will
> be deleted upon the next transaction, so no manual removal is needed.
>
> * Support was added for SCTP portcon statements. The corresponding
> kernel support was introduced in Linux 4.17, and is only active if the
> extended_socket_class policy capability is enabled in the policy.
>
> * sepol_polcap_getnum/name() were exported as part of the shared libsepol
> interface, initially for use by setools4.
>
> * semodule_deps was removed since it has long been broken and is not useful
> for CIL modules.
>
> Packaging-relevant changes:
>
> * When overriding PREFIX, BINDIR, SBINDIR, SHLIBDIR, LIBEXECDIR, etc.,
> DESTDIR has to be removed from the definition. For example on Arch
> Linux, SBINDIR="${pkgdir}/usr/bin" was changed to SBINDIR="/usr/bin".
>
> * Defining variable LIBSEPOLA (to /usr/lib/libsepol.a, for example) is
> no longer mandatory (thanks to the switch to "-l:libsepol.a" in
> Makefiles).
>
> * PYSITEDIR has been renamed PYTHONLIBDIR (and its definition changed).
>
> * selinux-gui (i.e. system-config-selinux GUI application) is now
> compatible with Python 3. Doing this required migrating away from
> PyGTK to the supported PyGI library. This means that selinux-gui now
> depends on python-gobject, Gtk+ 3 and selinux-python. It no longer
> requires PyGtk or Python 2.
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: Loopback TCP connection
On Fri, Apr 27, 2018 at 04:42:56PM +0200, Troels Arvin wrote: > Hello, > > On Fri, Apr 27, 2018 at 4:31 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote: > > > See: > > https://github.com/SELinuxProject/selinux-kernel/issues/21 > > https://bugzilla.redhat.com/show_bug.cgi?id=1168044 > > > > OK. So currently, it's not possible to write a policy item which allows > connections to sockets on the loopback interface only. > > In that case, I'll work on a patch proposal for a boolean to activate this: > allow tomcat_t smtp_port_t:tcp_socket name_connect; I think it should be possible to control egress/ingress on labeled interfaces > > -- > Regards, > Troels Arvin -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: CIL namespaces and blockinheritfilter keyword.
On Mon, Apr 09, 2018 at 01:41:12PM +0200, Lukas Vrabec wrote:
> On 04/09/2018 10:41 AM, Dominick Grift wrote:
> > On Mon, Apr 09, 2018 at 09:55:23AM +0200, Dominick Grift wrote:
> >> On Sun, Apr 08, 2018 at 11:00:53PM +0200, Lukas Vrabec wrote:
> >>> Hi All,
> >>>
> >>> I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN"
> >>> wiki page [1] and I'm interested in CIL namespaces. I tried several
> >>> examples related to blockinheritence and all works just great!
> >>>
> >>> However, in following example I see keyword "blockinheritfilter":
> >>>
> >>> (block logger
> >>> (blockabstract logger)
> >>> (type process)
> >>> (type log)
> >>> (allow process log (file (getattr append write
> >>>
> >>> (block myapp
> >>> (blockinherit logger)
> >>> (blockinheritfilter myapp logger
> >>> (allow process log (file (write)
> >>>
> >>
> >> The example above actually demonstrates that you do not need
> >> blockinheritfilter (and should not use it for this example), instead you
> >> can just append rules to blocks.
> >>
> >> loggers should not open the log file for write and so the main template
> >> should not include that permission in the first place:
> >>
> >> (block logger
> >>(blockabstract logger)
> >>(type process)
> >>(type log)
> >>(allow process log (file (getattr append
> >>
> >> Then if you have a misbehaving logger you can just append the bad rule to
> >> that block:
> >>
> >> (block badlogger
> >>(blockinherit logger)
> >>(allow process log (file (write)
> >
> > Or even:
> >
> > (block logger
> >(blockabstract logger)
> >(type process)
> >(type log)
> >(allow process log (file (getattr append
> >
> > (block badlogger
> >(blockabstract badlogger)
> >(blockinherit logger)
> >(allow process log (file (write
> >
> > (block yourlogger
> >(blockinherit badlogger))
> >
>
> Hi Dominick,
>
> Yes, This is one of the options to create hierarchy when the block on
> top will have just minimum rules and every child block will append new
> rules.
>
> Unfortunately, this probably won't work in real world. Let's say that I
> have this hierarchy and badlogger block contains several allow rules and
> I want to inherit all of them except one, *BUT* I'm not SELinux policy
> expert and don't know how hierarchy looks like. That's the reason why
> I'm looking for blockinheritfilter.
I forgot the reason for dropping this functionality (I do recall me asking
about this as well in the past but it seems that Google has no record of that)
and so I will leave it to others to respond to this part of the question.
>
> However, we should go via creating block namespaces hierarchy as you
> described if there are no plans to implement this feature.
>
> Thanks,
> Lukas.
>
> >>
> >> Appending instead of filtering probably just the better approach also if
> >> you consider that blocks might have macros or nested blocks
> >> You probably would not be able to filter any of those.
> >>
> >>
> >>>
> >>> If I understand it correctly, it should "remove" rule:
> >>> allow myapp.process log:file write;
> >>>
> >>> So process type in myapp should have allowed:
> >>> allow myapp.process log:file {getattr append};
> >>>
> >>> And process type in logger should have allowed:
> >>> allow logger.process log:file {getattr append write};
> >>>
> >>> Which could be very cool feature, but I don't see any code in secilc
> >>> related to "blockinheritfilter". Are there any plans to implement also
> >>> this in CIL namespaces or is there any other way how to handle this
> >>> (DELETE statement is also not implemented) ?
> >>>
> >>> Thanks for any help.
> >>> Lukas.
> >>>
> >>>
> >>> [1] https://github.com/SELinuxProject/cil/wiki
> >>>
> >>> --
> >>> Lukas Vrabec
> >>> Software Engineer, Security Technologies
> >>> Red Hat, Inc.
> >>>
> >>
> >>
> >>
> >>
> >> --
> >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> >> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> >> Dominick Grift
> >
> >
> >
>
>
> --
> Lukas Vrabec
> Software Engineer, Security Technologies
> Red Hat, Inc.
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: CIL namespaces and blockinheritfilter keyword.
On Mon, Apr 09, 2018 at 09:55:23AM +0200, Dominick Grift wrote:
> On Sun, Apr 08, 2018 at 11:00:53PM +0200, Lukas Vrabec wrote:
> > Hi All,
> >
> > I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN"
> > wiki page [1] and I'm interested in CIL namespaces. I tried several
> > examples related to blockinheritence and all works just great!
> >
> > However, in following example I see keyword "blockinheritfilter":
> >
> > (block logger
> > (blockabstract logger)
> > (type process)
> > (type log)
> > (allow process log (file (getattr append write
> >
> > (block myapp
> > (blockinherit logger)
> > (blockinheritfilter myapp logger
> > (allow process log (file (write)
> >
>
> The example above actually demonstrates that you do not need
> blockinheritfilter (and should not use it for this example), instead you can
> just append rules to blocks.
>
> loggers should not open the log file for write and so the main template
> should not include that permission in the first place:
>
> (block logger
>(blockabstract logger)
>(type process)
>(type log)
>(allow process log (file (getattr append
>
> Then if you have a misbehaving logger you can just append the bad rule to
> that block:
>
> (block badlogger
>(blockinherit logger)
>(allow process log (file (write)
Or even:
(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append
(block badlogger
(blockabstract badlogger)
(blockinherit logger)
(allow process log (file (write
(block yourlogger
(blockinherit badlogger))
>
> Appending instead of filtering probably just the better approach also if you
> consider that blocks might have macros or nested blocks
> You probably would not be able to filter any of those.
>
>
> >
> > If I understand it correctly, it should "remove" rule:
> > allow myapp.process log:file write;
> >
> > So process type in myapp should have allowed:
> > allow myapp.process log:file {getattr append};
> >
> > And process type in logger should have allowed:
> > allow logger.process log:file {getattr append write};
> >
> > Which could be very cool feature, but I don't see any code in secilc
> > related to "blockinheritfilter". Are there any plans to implement also
> > this in CIL namespaces or is there any other way how to handle this
> > (DELETE statement is also not implemented) ?
> >
> > Thanks for any help.
> > Lukas.
> >
> >
> > [1] https://github.com/SELinuxProject/cil/wiki
> >
> > --
> > Lukas Vrabec
> > Software Engineer, Security Technologies
> > Red Hat, Inc.
> >
>
>
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: CIL namespaces and blockinheritfilter keyword.
On Sun, Apr 08, 2018 at 11:00:53PM +0200, Lukas Vrabec wrote:
> Hi All,
>
> I'm reading "SELINUX COMMON INTERMEDIATE LANGUAGE MOTIVATION AND DESIGN"
> wiki page [1] and I'm interested in CIL namespaces. I tried several
> examples related to blockinheritence and all works just great!
>
> However, in following example I see keyword "blockinheritfilter":
>
> (block logger
> (blockabstract logger)
> (type process)
> (type log)
> (allow process log (file (getattr append write
>
> (block myapp
> (blockinherit logger)
> (blockinheritfilter myapp logger
> (allow process log (file (write)
>
The example above actually demonstrates that you do not need blockinheritfilter
(and should not use it for this example), instead you can just append rules to
blocks.
loggers should not open the log file for write and so the main template should
not include that permission in the first place:
(block logger
(blockabstract logger)
(type process)
(type log)
(allow process log (file (getattr append
Then if you have a misbehaving logger you can just append the bad rule to that
block:
(block badlogger
(blockinherit logger)
(allow process log (file (write)
Appending instead of filtering probably just the better approach also if you
consider that blocks might have macros or nested blocks
You probably would not be able to filter any of those.
>
> If I understand it correctly, it should "remove" rule:
> allow myapp.process log:file write;
>
> So process type in myapp should have allowed:
> allow myapp.process log:file {getattr append};
>
> And process type in logger should have allowed:
> allow logger.process log:file {getattr append write};
>
> Which could be very cool feature, but I don't see any code in secilc
> related to "blockinheritfilter". Are there any plans to implement also
> this in CIL namespaces or is there any other way how to handle this
> (DELETE statement is also not implemented) ?
>
> Thanks for any help.
> Lukas.
>
>
> [1] https://github.com/SELinuxProject/cil/wiki
>
> --
> Lukas Vrabec
> Software Engineer, Security Technologies
> Red Hat, Inc.
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: dbus-daemon patches review
On Thu, Mar 22, 2018 at 12:09:08PM -0400, Stephen Smalley wrote: > On 03/21/2018 07:58 AM, Laurent Bigonville wrote: > > Hello, > > > > Could somebody have a quick look at the two patches that I opened for two > > dbus bugs: > > > > https://bugs.freedesktop.org/show_bug.cgi?id=92831 (stop using avc_init()) > > > > https://bugs.freedesktop.org/attachment.cgi?id=138021 (stop using > > selinux_set_mapping()) > > > > I'm also wondering whether the call to avc_add_callback() shouldn't be > > replaced by selinux_set_callback(), an opinion on this? > > Patches look sane to me although I'm not really familiar with dbus code. > > Looks like the callback is only used to trigger a reload of the dbus > configuration (for dbus_contexts updates), and thus > selinux_set_callback(SELINUX_CB_POLICYLOAD) is more appropriate than > avc_add_callback(AVC_CALLBACK_RESET), since the latter is called upon > setenforce 1 as well. However, if it were truly only for that purpose, one > might argue that it ought to be a watch on the dbus_contexts file instead and > not be tied to selinux at all. > > NB This still won't fix the case where dbusd has already performed a > string_to_security_class/av_perm lookup and the result has been cached by the > libselinux class cache and then a subsequent policy update alters those > values. That is what was fixed for systemd's usage of selinux_check_access() > by selinux commit b408d72ca9104cb0c1bc4e154d8732cc7c0a9190. Offhand, I'm now > wondering why I didn't just call flush_class_cache() from avc_reset() itself. > That would fix it for other users of the AVC. You can't directly call > flush_class_cache() from the dbus selinux policyload callback because it is > hidden presently. If we can fix it directly in libselinux, then that is > better. If not, we'd need to export it and probably give it a more unique > name, ala selinux_flush_class_cache(). dbus-broker also uses selinux_access_check: https://github.com/bus1/dbus-broker/issues/16 > > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: Linux 4.16 cap_sys_module
On Wed, Feb 28, 2018 at 10:27:08AM +0100, Dominick Grift wrote:
> Since Linux 4.16 (to atleast RC2) user space started to excessively trigger
> cap_sys_module
>
> Here is one example of such and event:
>
> type=SYSCALL msg=audit(02/27/2018 08:06:40.017:74) : arch=x86_64
> syscall=ioctl success=no exit=ENOTTY(Inappropriate ioctl for device) a0=0x2
> a1=TCGETS a2=0x7fff2d89f8f0 a3=0x55ba203a9010 items=0 ppid=1 pid=423
> auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root
> sgid=root fsgid=root tty=(none) ses=unset comm=systemd-user-se
> exe=/usr/lib/systemd/systemd-user-sessions
> subj=sys.id:sys.role:user_sessions.subj:s0 key=(null)
> type=AVC msg=audit(02/27/2018 08:06:40.017:74) : avc: denied { sys_module }
> for pid=423 comm=systemd-user-se capability=sys_module
> scontext=sys.id:sys.role:user_sessions.subj:s0
> tcontext=sys.id:sys.role:user_sessions.subj:s0 tclass=capability permissive=1
> type=AVC msg=audit(02/27/2018 08:06:40.017:74) : avc: denied {
> module_request } for pid=423 comm=systemd-user-se
> kmod=6E65746465762D80E72A05257F
> scontext=sys.id:sys.role:user_sessions.subj:s0
> tcontext=sys.id:sys.role:sys.isid:s0 tclass=system permissive=1
>
> Any idea what causes this and how to fix it?
For reference:
https://github.com/fedora-selinux/selinux-policy/commit/2c13be1fb543c51935785e7a43b798a9f35f5aa0#comments
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Linux 4.16 cap_sys_module
Since Linux 4.16 (to atleast RC2) user space started to excessively trigger
cap_sys_module
Here is one example of such and event:
type=SYSCALL msg=audit(02/27/2018 08:06:40.017:74) : arch=x86_64 syscall=ioctl
success=no exit=ENOTTY(Inappropriate ioctl for device) a0=0x2 a1=TCGETS
a2=0x7fff2d89f8f0 a3=0x55ba203a9010 items=0 ppid=1 pid=423 auid=unset uid=root
gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root
tty=(none) ses=unset comm=systemd-user-se
exe=/usr/lib/systemd/systemd-user-sessions
subj=sys.id:sys.role:user_sessions.subj:s0 key=(null)
type=AVC msg=audit(02/27/2018 08:06:40.017:74) : avc: denied { sys_module }
for pid=423 comm=systemd-user-se capability=sys_module
scontext=sys.id:sys.role:user_sessions.subj:s0
tcontext=sys.id:sys.role:user_sessions.subj:s0 tclass=capability permissive=1
type=AVC msg=audit(02/27/2018 08:06:40.017:74) : avc: denied { module_request
} for pid=423 comm=systemd-user-se kmod=6E65746465762D80E72A05257F
scontext=sys.id:sys.role:user_sessions.subj:s0
tcontext=sys.id:sys.role:sys.isid:s0 tclass=system permissive=1
Any idea what causes this and how to fix it?
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
[PATCH] Describe multiple-decls in secilc.8.xml
Signed-off-by: Dominick Grift <dac.overr...@gmail.com> --- secilc/secilc.8.xml | 5 + 1 file changed, 5 insertions(+) diff --git a/secilc/secilc.8.xml b/secilc/secilc.8.xml index 4c779b64..e08a9624 100644 --- a/secilc/secilc.8.xml +++ b/secilc/secilc.8.xml @@ -75,6 +75,11 @@ Treat tunables as booleans. + +-m, --multiple-decls +Allow some statements to be re-declared. + + -N, --disable-neverallow Do not check neverallow rules. -- 2.16.1
Re: CIL: should this work?
On Wed, Jan 31, 2018 at 09:56:56PM +0100, Dominick Grift wrote: > I have a template (blockabstract): foo.bar.template > > in another module i want to inherit that like this: > > (in foo > (block baz > (blockinherit bar.template))) > > This does not seem to work fully. nvm i think my template is faulty > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > Dominick Grift -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
CIL: should this work?
I have a template (blockabstract): foo.bar.template in another module i want to inherit that like this: (in foo (block baz (blockinherit bar.template))) This does not seem to work fully. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: default_type limitations
On Fri, Jan 19, 2018 at 11:43:33AM +0100, Dominick Grift wrote: > On Fri, Jan 19, 2018 at 11:34:37AM +0100, Dominick Grift wrote: > > On Fri, Jan 19, 2018 at 11:19:51AM +0100, Dominick Grift wrote: > > > The default_type functionality is too limited because it assumes that all > > > login programs associate the same type with a given role > > > > > > This is not the case > > > > > > For example: > > > > > > default_type for local_login: joe.role:joe.type > > > default_type for sshd: joe.role:joe_ssh_server.type > > > default_type for cockpit joe.role:joe_cockpit_bridge.type > > > > The thing is that login programs these day's often dont just run a shell on > > behalf of users directly. > > There is often an intermediate process that should not be associated with > > the shell type ideally > > > > For example sshd uses pam_selinux to associate a context with the > > privileged user sshd process. This process needs > > all kinds of extra permissions for tunneling, forwarding, chroots etc. > > > > this privileged process then runs a shell on half of the user: > > > > sshd -> user "priv" sshd process -> user shell > > > > This works because it uses pam_selinux for the user "priv" sshd manual > > process transition, and then i can use a transparent automatic type > > transition to associate a context with the shell (user_sshd.type -> shell > > -> user.type) > > > > Same with cockpit: > > cockpits_session -> user cockpit bridge -> user shell > > > > unlike local_login: > > login -> user shell > > I other words: There is no such thing as a "default_type". The default type > associated with a given role can vary per login program. hmm, never mind. I will have to investigate further... looks like i got confused > > > > > > > > > etc > > > > > > So pam_selinux "select_context" can only support a single login program > > > due to this > > > > > > I do not understand why default_type is needed in the first place. The > > > contexts/users/ file is more specific: > > > > > > /etc/selinux/TYPE/contexts/users/joe.user: > > > sys.role:login.type:s0 joe.role:joe.type:s0 joe1.role:joe1.type:s0 > > > sys.role:sshd.type:s0 joe.role:joe_ssh_server.type:s0 > > > joe1.role:joe1_ssh_server.type:s0 > > > sys.role:cockpit_session.subj:s0 joe.role:joe_cockpit_bridge.type:s0 > > > joe1:joe1_cockpit_bridge.type:s0 > > > > > > ie. its already specified that for example joe1.type is default type for > > > joe1.role for local_login and that joe1_ssh_server.type is default type > > > for joe1.role for sshd > > > > > > So unless i am overlooking something, the default_type file is redundant > > > and it actually adds an extra file to configure > > > > > > -- > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > > > Dominick Grift > > > > > > > > -- > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > > Dominick Grift > > > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > Dominick Grift -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: default_type limitations
On Fri, Jan 19, 2018 at 11:34:37AM +0100, Dominick Grift wrote: > On Fri, Jan 19, 2018 at 11:19:51AM +0100, Dominick Grift wrote: > > The default_type functionality is too limited because it assumes that all > > login programs associate the same type with a given role > > > > This is not the case > > > > For example: > > > > default_type for local_login: joe.role:joe.type > > default_type for sshd: joe.role:joe_ssh_server.type > > default_type for cockpit joe.role:joe_cockpit_bridge.type > > The thing is that login programs these day's often dont just run a shell on > behalf of users directly. > There is often an intermediate process that should not be associated with the > shell type ideally > > For example sshd uses pam_selinux to associate a context with the privileged > user sshd process. This process needs > all kinds of extra permissions for tunneling, forwarding, chroots etc. > > this privileged process then runs a shell on half of the user: > > sshd -> user "priv" sshd process -> user shell > > This works because it uses pam_selinux for the user "priv" sshd manual > process transition, and then i can use a transparent automatic type > transition to associate a context with the shell (user_sshd.type -> shell -> > user.type) > > Same with cockpit: > cockpits_session -> user cockpit bridge -> user shell > > unlike local_login: > login -> user shell I other words: There is no such thing as a "default_type". The default type associated with a given role can vary per login program. > > > > > etc > > > > So pam_selinux "select_context" can only support a single login program due > > to this > > > > I do not understand why default_type is needed in the first place. The > > contexts/users/ file is more specific: > > > > /etc/selinux/TYPE/contexts/users/joe.user: > > sys.role:login.type:s0 joe.role:joe.type:s0 joe1.role:joe1.type:s0 > > sys.role:sshd.type:s0 joe.role:joe_ssh_server.type:s0 > > joe1.role:joe1_ssh_server.type:s0 > > sys.role:cockpit_session.subj:s0 joe.role:joe_cockpit_bridge.type:s0 > > joe1:joe1_cockpit_bridge.type:s0 > > > > ie. its already specified that for example joe1.type is default type for > > joe1.role for local_login and that joe1_ssh_server.type is default type for > > joe1.role for sshd > > > > So unless i am overlooking something, the default_type file is redundant > > and it actually adds an extra file to configure > > > > -- > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > > Dominick Grift > > > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > Dominick Grift -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: default_type limitations
On Fri, Jan 19, 2018 at 11:19:51AM +0100, Dominick Grift wrote: > The default_type functionality is too limited because it assumes that all > login programs associate the same type with a given role > > This is not the case > > For example: > > default_type for local_login: joe.role:joe.type > default_type for sshd: joe.role:joe_ssh_server.type > default_type for cockpit joe.role:joe_cockpit_bridge.type The thing is that login programs these day's often dont just run a shell on behalf of users directly. There is often an intermediate process that should not be associated with the shell type ideally For example sshd uses pam_selinux to associate a context with the privileged user sshd process. This process needs all kinds of extra permissions for tunneling, forwarding, chroots etc. this privileged process then runs a shell on half of the user: sshd -> user "priv" sshd process -> user shell This works because it uses pam_selinux for the user "priv" sshd manual process transition, and then i can use a transparent automatic type transition to associate a context with the shell (user_sshd.type -> shell -> user.type) Same with cockpit: cockpits_session -> user cockpit bridge -> user shell unlike local_login: login -> user shell > > etc > > So pam_selinux "select_context" can only support a single login program due > to this > > I do not understand why default_type is needed in the first place. The > contexts/users/ file is more specific: > > /etc/selinux/TYPE/contexts/users/joe.user: > sys.role:login.type:s0 joe.role:joe.type:s0 joe1.role:joe1.type:s0 > sys.role:sshd.type:s0 joe.role:joe_ssh_server.type:s0 > joe1.role:joe1_ssh_server.type:s0 > sys.role:cockpit_session.subj:s0 joe.role:joe_cockpit_bridge.type:s0 > joe1:joe1_cockpit_bridge.type:s0 > > ie. its already specified that for example joe1.type is default type for > joe1.role for local_login and that joe1_ssh_server.type is default type for > joe1.role for sshd > > So unless i am overlooking something, the default_type file is redundant and > it actually adds an extra file to configure > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > Dominick Grift -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
default_type limitations
The default_type functionality is too limited because it assumes that all login programs associate the same type with a given role This is not the case For example: default_type for local_login: joe.role:joe.type default_type for sshd: joe.role:joe_ssh_server.type default_type for cockpit joe.role:joe_cockpit_bridge.type etc So pam_selinux "select_context" can only support a single login program due to this I do not understand why default_type is needed in the first place. The contexts/users/ file is more specific: /etc/selinux/TYPE/contexts/users/joe.user: sys.role:login.type:s0 joe.role:joe.type:s0 joe1.role:joe1.type:s0 sys.role:sshd.type:s0 joe.role:joe_ssh_server.type:s0 joe1.role:joe1_ssh_server.type:s0 sys.role:cockpit_session.subj:s0 joe.role:joe_cockpit_bridge.type:s0 joe1:joe1_cockpit_bridge.type:s0 ie. its already specified that for example joe1.type is default type for joe1.role for local_login and that joe1_ssh_server.type is default type for joe1.role for sshd So unless i am overlooking something, the default_type file is redundant and it actually adds an extra file to configure -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: PAM Security related issue
1. cat /etc/selinux/targeted/contexts/users/specialuser_u 2. priv logins are allowed as per the ssh_priv_logins boolean? 3. do you get the same result when you associate "sftpuser" with selinux user "user_u"? On Thu, Dec 14, 2017 at 12:48:42PM +0530, Aman Sharma wrote: > Hi All, > > Below is the output of semanage USer command output for sftpuser: > > *specialuser_u user s0 s0 > sysadm_r system_r* > > and for command semanage login -l , output is : > > *sftpuser specialuser_us0 ** > > *and also, after adding the debugging option, its showing the below error > message as :* > > Dec 13 15:46:10 cucmSUB authpriv 3 sshd: pam_selinux(sshd:session): Unable > to get valid context for sftpuser > > Dec 13 15:46:10 cucmSUB authpriv 5 sshd: pam_selinux(sshd:session): Open > Session > > Dec 13 15:46:11 cucmSUB authpriv 7 sshd: pam_selinux(sshd:session): > Username= sftpuser SELinux User= specialuser_u Level= s0 > > Dec 13 15:46:11 cucmSUB authpriv 3 sshd: pam_selinux(sshd:session): Unable > to get valid context for sftpuser > > > also Selinuxdefcon command is showing error while running for sftpuser i.e. > > *sudo /usr/sbin/selinuxdefcon sftpuser system_u:system_r:sshd_t:s0* > > */usr/sbin/selinuxdefcon: Invalid argument* > > > *Please let me know your comments on this.* > > > *Thanks* > > *Aman* > > On Thu, Dec 14, 2017 at 12:45 AM, Stephen Smalley <s...@tycho.nsa.gov> wrote: > > > On Wed, 2017-12-13 at 21:40 +0530, Aman Sharma wrote: > > > Hi Stephen, > > > > > > Yes , I am using open env_params for it. But for this, my sftp is not > > > working and getting the below error message : > > > > > > Dec 13 13:00:00 aman authpriv 3 sshd: pam_selinux(sshd:session): > > > Unable to get valid context for sftpuser > > > Dec 13 13:00:00 aman authpriv 6 sshd: pam_unix(sshd:session): session > > > opened for user sftpuser by (uid=0) > > > > > > Please let me know if you have any idea on this. > > > > Do you have any semanage login mapping for sftpuser or is it just using > > the __default__ entry? (what does semanage login -l show) How was > > sftpuser created? > > > > You could add the debug option on the pam_selinux.so line to try to get > > more information. > > > > You could run selinuxdefcon to query what context would be used for > > that user, e.g. > > selinuxdefcon sftpuser system_u:system_r:sshd_t:s0-s0.c0123 > > > > > > > > On Wed, Dec 13, 2017 at 8:54 PM, Stephen Smalley <s...@tycho.nsa.gov> > > > wrote: > > > > On Tue, 2017-12-12 at 23:47 -0500, Aman Sharma wrote: > > > > > Hi All, > > > > > > > > > > just wanted to know the meaning of line sessionrequired > > > > > pam_selinux.so open env_params added in /etc/pam.d/sshd file. > > > > > Actually I am facing one issue related to this. When I changed > > > > this > > > > > env_params to restore then my Sftp is not working. > > > > > > > > > > Can anybody Please guide me on this. > > > > > > > > man pam_selinux describes the options and what they mean. > > > > Why did you change it to restore? Per the man page, restore is to > > > > temporarily restore the contexts and would be a separate entry in > > > > the > > > > PAM stack before the module that needs the original contexts, > > > > followed > > > > by a pam_selinux.so open env_params after that module to set them > > > > up > > > > again. But don't use restore unless you actually need it for some > > > > reason. > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Thanks > > > Aman > > > Cell: +91 9990296404 | Email ID : amansh.shar...@gmail.com > > > > > > -- > > Thanks > Aman > Cell: +91 9990296404 | Email ID : amansh.shar...@gmail.com -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: PAM Security related issue
On Wed, Dec 13, 2017 at 09:40:25PM +0530, Aman Sharma wrote: > Hi Stephen, > > Yes , I am using open env_params for it. But for this, my sftp is not > working and getting the below error message : > > Dec 13 13:00:00 aman authpriv 3 sshd: pam_selinux(sshd:session): Unable to > get valid context for sftpuser > Dec 13 13:00:00 aman authpriv 6 sshd: pam_unix(sshd:session): session > opened for user sftpuser by (uid=0) Not sure if this is actually the issue but: AFAIK the user must have access to "context contains" for env_params See if the context assoc. with the sftpuser process has access to context contains > > Please let me know if you have any idea on this. > > On Wed, Dec 13, 2017 at 8:54 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote: > > > On Tue, 2017-12-12 at 23:47 -0500, Aman Sharma wrote: > > > Hi All, > > > > > > just wanted to know the meaning of line sessionrequired > > > pam_selinux.so open env_params added in /etc/pam.d/sshd file. > > > Actually I am facing one issue related to this. When I changed this > > > env_params to restore then my Sftp is not working. > > > > > > Can anybody Please guide me on this. > > > > man pam_selinux describes the options and what they mean. > > Why did you change it to restore? Per the man page, restore is to > > temporarily restore the contexts and would be a separate entry in the > > PAM stack before the module that needs the original contexts, followed > > by a pam_selinux.so open env_params after that module to set them up > > again. But don't use restore unless you actually need it for some > > reason. > > > > > > > > > > > -- > > Thanks > Aman > Cell: +91 9990296404 | Email ID : amansh.shar...@gmail.com -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: Qwery regarding Selinux Change Id context
s > > > > from sshd. > > > > Also try the selinuxdefcon command I mentioned. > > > > > > > > > > > > > > On Mon, Dec 4, 2017 at 9:10 PM, Stephen Smalley <s...@tycho.nsa.go > > > > v> > > > > > wrote: > > > > > > On Sat, 2017-12-02 at 09:29 +0530, Aman Sharma wrote: > > > > > > > Hi All, > > > > > > > > > > > > > > Thanks for the information. > > > > > > > > > > > > > > But after resetting the semanage User/login, and moving the > > > > > > targeted > > > > > > > folder to old one and then install the default target. then > > > > also > > > > > > its > > > > > > > still showing the > > > > > > > Id context as context=system_u:system_r:unconfined_t:s0- > > > > > > s0:c0.c1023. > > > > > > > > > > > > > > What I observed is after changing the permission using > > > > semanage > > > > > > > command also, its still showing the system_u:system_r. > > > > > > > > > > > > > > Check the semanage login/User output : > > > > > > > > > > > > > > semanage login -l > > > > > > > > > > > > > > Login Name SELinux User MLS/MCS Range > > > > > > > > > > > Service > > > > > > > > > > > > > > __default__ unconfined_u s0-s0:c0.c1023 > > > > * > > > > > > > root unconfined_u s0-s0:c0.c1023 > > > > * > > > > > > > system_u system_u s0-s0:c0.c1023 > > > > * > > > > > > > > > > > > > > > > > > > > > semanage user -l > > > > > > > > > > > > > > Labeling MLS/ MLS/ > > > > > > > > > > > > > > > > > SELinux UserPrefix MCS Level MCS Range > > > > > > > > > > > > > > > > > SELinux Roles > > > > > > > > > > > > > > guest_u user s0 s0 > > > > > > > > > > > > > > > > > guest_r > > > > > > > rootuser s0 s0-s0:c0.c1023 > > > > > > > > > > > > > > > > > staff_r sysadm_r system_r unconfined_r > > > > > > > staff_u user s0 s0-s0:c0.c1023 > > > > > > > > > > > > > > > > > staff_r sysadm_r system_r unconfined_r > > > > > > > sysadm_uuser s0 s0-s0:c0.c1023 > > > > > > > > > > > > > > > > > sysadm_r > > > > > > > system_uuser s0 s0-s0:c0.c1023 > > > > > > > > > > > > > > > > > system_r unconfined_r > > > > > > > unconfined_uuser s0 s0-s0:c0.c1023 > > > > > > > > > > > > > > > > > system_r unconfined_r > > > > > > > user_u user s0 s0 > > > > > > > > > > > > > > > > > user_r > > > > > > > xguest_uuser s0 s0 > > > > > > > > > > > > > > > > > xguest_r > > > > > > > > > > > > > > > > > > > > > Looks like its related to some other issue. What you think > > > > about > > > > > > > this. > > > > > > > > > > > > Do you have any relevant error messages in /var/log/secure or > > > > > > journalctl -rb? Look for anything that refers to selinux or > > > > > > context. > > > > > > > > > > > > I'm guessing that pam_selinux is unable to determine a valid > > > > > > context > > > > > > for your login for some reason, and this is causing it to fall > > > > back > > > > > > to > > > > > > this one. Or something like that. > > > > > > > > > > > > You could try to emulate this process via selinuxdefcon, > > > > although > > > > > > I'm > > > > > > not sure how closely it matches pam_selinux anymore. Sample > > > > usage: > > > > > > > > > > > > 1. See what context sshd is running in. > > > > > > > > > > > > ps -eZ | grep sshd > > > > > > > > > > > > It should be: > > > > > > system_u:system_r:sshd_t:s0-s0:c0.c1023 > > > > > > > > > > > > 2. Run selinuxdefcon to compute the default context for root > > > > when > > > > > > logging in from sshd: > > > > > > > > > > > > # Second argument should be whatever was shown by ps -eZ | grep > > > > > > sshd > > > > > > above. > > > > > > selinuxdefcon root system_u:system_r:sshd_t:s0-s0.c0123 > > > > > > > > > > > > It should be: > > > > > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > Thanks > > > > > Aman > > > > > Cell: +91 9990296404 | Email ID : amansh.shar...@gmail.com > > > > > > > > > > > > > > > > -- > > > > > > Thanks > > > Aman > > > Cell: +91 9990296404 | Email ID : amansh.shar...@gmail.com > > > > > > -- > > Thanks > Aman > Cell: +91 9990296404 | Email ID : amansh.shar...@gmail.com -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: Fwd: Qwery regarding Selinux Change Id context
On Thu, Nov 30, 2017 at 11:10:43AM +0530, Aman Sharma wrote: > Hi Stephen, > > After reseting Selinux targeted folder also (the steps you mentioned in the > earlier mail), Still its showing the same Id context i.e. > > *id* > *uid=0(root) gid=0(root) groups=0(root) > context=system_u:system_r:unconfined_t:s0-s0:c0.c1023* > *[root@cucm2 ~]# id -Z* > *system_u:system_r:unconfined_t:s0-s0:c0.c1023* > > *And semanage login -l is showing blank output. * > > *Do you have any idea about this.* > > *Thanks* > *Aman* Try the same procedure again but this time also do before reinstalling: mv /var/lib/selinux/targeted /var/lib/selinux/targeted.old > > > On Wed, Nov 29, 2017 at 11:04 PM, Stephen Smalley <s...@tycho.nsa.gov> wrote: > > > On Wed, 2017-11-29 at 22:01 +0530, Aman Sharma wrote: > > > After resetting boolean also, showing the same id context. > > > > And did you try fully resetting your policy as I suggested: > > mv /etc/selinux/targeted /etc/selinux/targeted.old > > yum reinstall selinux-policy-targeted > > reboot > > > > > > > > > > > On Wed, Nov 29, 2017 at 9:50 PM, Stephen Smalley <s...@tycho.nsa.gov> > > > wrote: > > > > On Wed, 2017-11-29 at 21:39 +0530, Aman Sharma wrote: > > > > > Hi Stephen, > > > > > > > > > > After enabling the unconfined module and after reboot also, Still > > > > > showing the same id context. > > > > > > > > > > Is there any way to make the id context to normal state again ? > > > > > > > > Hmmm...try resetting all booleans too? semanage boolean -D > > > > > > > > Or you could be drastic and completely reset your policy: > > > > mv /etc/selinux/targeted /etc/selinux/targeted.old > > > > yum reinstall selinux-policy-targeted > > > > > > > > > > > > > > > > -- > > > > > > Thanks > > > Aman > > > Cell: +91 9990296404 | Email ID : amansh.shar...@gmail.com > > > > > > -- > > Thanks > Aman > Cell: +91 9990296404 | Email ID : amansh.shar...@gmail.com -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: Fwd: Qwery regarding Selinux Change Id context
On Wed, Nov 29, 2017 at 02:21:46PM +0530, Aman Sharma wrote: > Hi , > > Check the output for the same. > > * getsebool -a | grep ssh* > fenced_can_ssh --> off > selinuxuser_use_ssh_chroot --> on > ssh_chroot_rw_homedirs --> off > ssh_keysign --> off > ssh_sysadm_login --> on Thanks. That means I was wrong. > > > On Wed, Nov 29, 2017 at 1:52 PM, Dominick Grift <dac.overr...@gmail.com> > wrote: > > > On Wed, Nov 29, 2017 at 09:33:31AM +0530, Aman Sharma wrote: > > > Hi Stephen, > > > > > > Below is the output of command : > > > > > > * sestatus -v output* > > > *SELinux status: enabled* > > > *SELinuxfs mount:/sys/fs/selinux* > > > *SELinux root directory: /etc/selinux* > > > *Loaded policy name: targeted* > > > *Current mode: enforcing* > > > *Mode from config file: permissive* > > > *Policy MLS status: enabled* > > > *Policy deny_unknown status: allowed* > > > *Max kernel policy version: 28* > > > > > > *Process contexts:* > > > *Current context: > > > system_u:system_r:unconfined_t:s0-s0:c0.c1023* > > > *Init context: system_u:system_r:init_t:s0* > > > */usr/sbin/sshd system_u:system_r:sshd_t:s0- > > s0:c0.c1023* > > > > > > *File contexts:* > > > *Controlling terminal: system_u:object_r:sshd_devpts_t:s0* > > > */etc/passwd system_u:object_r:passwd_file_t:s0* > > > */etc/shadow system_u:object_r:shadow_t:s0* > > > */bin/bash system_u:object_r:shell_exec_t:s0* > > > */bin/login system_u:object_r:login_exec_t:s0* > > > */bin/sh system_u:object_r:bin_t:s0 -> > > > system_u:object_r:shell_exec_t:s0* > > > */sbin/agettysystem_u:object_r:getty_exec_t:s0* > > > */sbin/init system_u:object_r:bin_t:s0 -> > > > system_u:object_r:init_exec_t:s0* > > > */usr/sbin/sshd system_u:object_r:sshd_exec_t:s0* > > > */lib/libc.so.6 system_u:object_r:lib_t:s0 -> > > > system_u:object_r:lib_t:s0* > > > */lib/ld-linux.so.2 system_u:object_r:lib_t:s0 -> > > > system_u:object_r:ld_so_t:s0* > > > > > > *Also I am using ssh session for login.* > > > > > > *Please let me know how to change id command context to unconfined_u or > > > Sysadm_u.* > > > > > > Thanks in advance > > > Aman > > > > not sure and shot in dark, but: > > > > root is assoc. with sysadm_u. sysadm_u is only authorized to use sysadm_r. > > if you have the boolean ssh_priv_login set to off then > > sysadm_u:sysadm_r:sysadm_t:s0 is inaccessible > > pam_selinux attempts to use any other contexts that are accessible, and it > > appears that system_u:system_r:unconfined_t was it. > > > > Do you have the ssh_priv_login boolean set to off? `getsebool -a | grep > > ssh` > > > > > > > > On Mon, Nov 27, 2017 at 9:29 PM, Stephen Smalley <s...@tycho.nsa.gov> > > wrote: > > > > > > > On Fri, 2017-11-24 at 10:47 +0530, Aman Sharma wrote: > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > Currently Working on Cent OS 7.3 and login as a root User and my Id > > > > > command output is : > > > > > > > > > > id > > > > > uid=0(root) gid=0(root) groups=0(root) > > > > > context=system_u:system_r:unconfined_t:s0-s0:c0.c1023 > > > > > > > > > > I want to change System_u:system_r:unconfined_t to sysadm_u:sysadm_r > > > > > or unconfined_u:unconfined_r. > > > > > > > > > > Also showing the output of following command : > > > > > > > > > > semanage user -l > > > > > > > > > > Labeling MLS/ MLS/ > > > > > SELinux UserPrefix MCS Level MCS Range > > > > > SELinux Roles > > > > > > > > > > admin_u user s0 s0-s0:c0.c1023 > > > > > sysadm_r system_r > > > > > guest_u user s0 s0 > > > > > guest_r > > > > > rootuser s0
Re: Fwd: Qwery regarding Selinux Change Id context
pwrecovery specialuser_us0 * > > > root sysadm_u s0-s0:c0.c1023 * > > > sftpuser specialuser_us0 * > > > system_u sysadm_u s0-s0:c0.c1023 * > > > > > > > > > Can anybody Please help me. > > > > What is your sestatus -v output? How are you logging in (console, gdm, > > ssh, ...)? > > > > You don't appear to be running the default policy, or if you are, > > someone has heavily customized your user and login mappings. > > > > > > > > > -- > > Thanks > Aman > Cell: +91 9990296404 | Email ID : amansh.shar...@gmail.com -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: with extended_socket_class should be still be seeing "socket"?
On Tue, Sep 12, 2017 at 12:01:35PM -0400, Stephen Smalley wrote:
> On Sep 12, 2017 7:01 AM, "Dominick Grift" <dac.overr...@gmail.com> wrote:
>
> I have extended socket class polcap enabled but i am still seeing "socket"
> class events and i was wondering whether that is to be expected?
>
> avc: denied { create } for pid=10484 comm="nethogs" scontext=wheel.id:
> sysadm.role:nethogs.subj:s0 tcontext=wheel.id:sysadm.role:nethogs.subj:s0
> tclass=socket permissive=0
>
> This seems to be common to processes that also create (and map! [1])
> "packet_socket" sockets (tcpdump/nethogs)
>
> [1] avc: denied { map } for pid=10525 comm="nethogs"
> path="socket:[56040]" dev="sockfs" ino=56040
> scontext=wheel.id:sysadm.role:nethogs.subj:s0
> tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=packet_socket
> permissive=0
>
>
> No, that is not expected. Can you enable sys call audit and get those
> records?
type=PROCTITLE msg=audit(09/12/2017 19:35:54.063:4458) : proctitle=nethogs
enp8s0
type=SYSCALL msg=audit(09/12/2017 19:35:54.063:4458) : arch=x86_64
syscall=socket success=yes exit=5 a0=local a1=SOCK_RAW a2=ip a3=0xb4 items=0
ppid=3251 pid=8963 auid=kcinimod uid=root gid=root euid=root suid=root
fsuid=root egid=root sgid=root fsgid=root tty=pts5 ses=1 comm=nethogs
exe=/usr/sbin/nethogs subj=wheel.id:sysadm.role:nethogs.subj:s0 key=(null)
type=AVC msg=audit(09/12/2017 19:35:54.063:4458) : avc: denied { create } for
pid=8963 comm=nethogs scontext=wheel.id:sysadm.role:nethogs.subj:s0
tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=socket permissive=1
type=PROCTITLE msg=audit(09/12/2017 19:35:07.983:4457) : proctitle=nethogs
enp8s0
type=MMAP msg=audit(09/12/2017 19:35:07.983:4457) : fd=5 flags=MAP_SHARED
type=SYSCALL msg=audit(09/12/2017 19:35:07.983:4457) : arch=x86_64 syscall=mmap
success=yes exit=140169557827584 a0=0x0 a1=0x20 a2=PROT_READ|PROT_WRITE
a3=MAP_SHARED items=0 ppid=3251 pid=8907 auid=kcinimod uid=root gid=root
euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts5 ses=1
comm=nethogs exe=/usr/sbin/nethogs subj=wheel.id:sysadm.role:nethogs.subj:s0
key=(null)
type=AVC msg=audit(09/12/2017 19:35:07.983:4457) : avc: denied { map } for
pid=8907 comm=nethogs path=socket:[103238] dev="sockfs" ino=103238
scontext=wheel.id:sysadm.role:nethogs.subj:s0
tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=packet_socket permissive=1
>
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
with extended_socket_class should be still be seeing "socket"?
I have extended socket class polcap enabled but i am still seeing "socket"
class events and i was wondering whether that is to be expected?
avc: denied { create } for pid=10484 comm="nethogs"
scontext=wheel.id:sysadm.role:nethogs.subj:s0
tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=socket permissive=0
This seems to be common to processes that also create (and map! [1])
"packet_socket" sockets (tcpdump/nethogs)
[1] avc: denied { map } for pid=10525 comm="nethogs" path="socket:[56040]"
dev="sockfs" ino=56040 scontext=wheel.id:sysadm.role:nethogs.subj:s0
tcontext=wheel.id:sysadm.role:nethogs.subj:s0 tclass=packet_socket permissive=0
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 04:30:36PM +0200, Dominick Grift wrote: > On Thu, Sep 07, 2017 at 03:56:36PM +0200, Dominick Grift wrote: > > On Thu, Sep 07, 2017 at 03:50:02PM +0200, Dominick Grift wrote: > > > On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote: > > > > On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote: > > > > > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote: > > > > > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote: > > > > > > > pam_selinux requirements are generally pretty simple: its used to > > > > > > > associate a context with a login shell. > > > > > > > > > > > > > > With systemd things have becomes a bit more complicated. > > > > > > > > > > > > > > systemd uses pam_selinux to associate a context with both a login > > > > > > > shell (via container-shell@.service) as well as with a systemd > > > > > > > --user > > > > > > > instance. > > > > > > > > > > > > > > Ideally one would not associate a login shell context with a > > > > > > > systemd > > > > > > > --user instance because a systemd --user instance needs > > > > > > > permissions > > > > > > > that do not make sense for a login shell to have. > > > > > > > > > > > > > > I am not aware of any way to make pam_selinux associate a context > > > > > > > based on variable like for example: if its a login shell then > > > > > > > associate this context , and if its a systemd --user instance then > > > > > > > associate that context > > > > > > > > > > > > > > This is an issue for me currently because if users are allowed to > > > > > > > "host-shell" (machinectl shell .host) then they are able to open a > > > > > > > shell with the context of the systemd --user instance and escape > > > > > > > their shell restrictions > > > > > > > > > > > > > > For now I can just block host-shell access with polkit but I am > > > > > > > trying to figure out what it would take to address this challenge > > > > > > > with pam_selinux > > > > > > > > > > > > The logic for determining a security context from pam_selinux (using > > > > > > libselinux get_ordered_context_with_level) can take the source/from > > > > > > context (i.e. the context in which the caller of pam_selinux is > > > > > > running > > > > > > ) into account as a factor in selecting which context to use, since > > > > > > it > > > > > > checks reachability (transition permission) as part of > > > > > > security_compute_user(). So that's a possible approach if you can > > > > > > distinguish what contexts are reachable for systemd --user vs login > > > > > > daemons. > > > > > > > > > > The challenge here is that the source/from context is the same > > > > > whether systemd --system spawns a login shell on behalf of a login > > > > > user or whether systemd --system spawns a systemd --user instance on > > > > > behalf of a login user > > > > > > > > > > > > > > > > > What SELinux permissions are required to host-shell? Can you block > > > > > > that via SELinux policy rather than just polkit? > > > > > > > > > > Might be possible but probably tricky. Not sure what it would take. > > > > > > > > > > machinectl shell can also be used to spawn a shell in a container and > > > > > this doesnt use pam_selinux, only machinectl shell .host makes > > > > > systemd --system use pam_selinux to determine the pam characteristics > > > > > to associate with the login shell on the host for the user > > > > > > > > > > So "machinectl shell $container" makes machinectl itself a shell in > > > > > $container (no pam), and "machinectl shell .host" makes machinectl > > > > > tell systemd --system to spawn a login shell on the host (where > > > > > systemd --system is using pam_selinux) > > > > > > > &
Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 03:56:36PM +0200, Dominick Grift wrote: > On Thu, Sep 07, 2017 at 03:50:02PM +0200, Dominick Grift wrote: > > On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote: > > > On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote: > > > > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote: > > > > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote: > > > > > > pam_selinux requirements are generally pretty simple: its used to > > > > > > associate a context with a login shell. > > > > > > > > > > > > With systemd things have becomes a bit more complicated. > > > > > > > > > > > > systemd uses pam_selinux to associate a context with both a login > > > > > > shell (via container-shell@.service) as well as with a systemd > > > > > > --user > > > > > > instance. > > > > > > > > > > > > Ideally one would not associate a login shell context with a systemd > > > > > > --user instance because a systemd --user instance needs permissions > > > > > > that do not make sense for a login shell to have. > > > > > > > > > > > > I am not aware of any way to make pam_selinux associate a context > > > > > > based on variable like for example: if its a login shell then > > > > > > associate this context , and if its a systemd --user instance then > > > > > > associate that context > > > > > > > > > > > > This is an issue for me currently because if users are allowed to > > > > > > "host-shell" (machinectl shell .host) then they are able to open a > > > > > > shell with the context of the systemd --user instance and escape > > > > > > their shell restrictions > > > > > > > > > > > > For now I can just block host-shell access with polkit but I am > > > > > > trying to figure out what it would take to address this challenge > > > > > > with pam_selinux > > > > > > > > > > The logic for determining a security context from pam_selinux (using > > > > > libselinux get_ordered_context_with_level) can take the source/from > > > > > context (i.e. the context in which the caller of pam_selinux is > > > > > running > > > > > ) into account as a factor in selecting which context to use, since it > > > > > checks reachability (transition permission) as part of > > > > > security_compute_user(). So that's a possible approach if you can > > > > > distinguish what contexts are reachable for systemd --user vs login > > > > > daemons. > > > > > > > > The challenge here is that the source/from context is the same whether > > > > systemd --system spawns a login shell on behalf of a login user or > > > > whether systemd --system spawns a systemd --user instance on behalf of > > > > a login user > > > > > > > > > > > > > > What SELinux permissions are required to host-shell? Can you block > > > > > that via SELinux policy rather than just polkit? > > > > > > > > Might be possible but probably tricky. Not sure what it would take. > > > > > > > > machinectl shell can also be used to spawn a shell in a container and > > > > this doesnt use pam_selinux, only machinectl shell .host makes systemd > > > > --system use pam_selinux to determine the pam characteristics to > > > > associate with the login shell on the host for the user > > > > > > > > So "machinectl shell $container" makes machinectl itself a shell in > > > > $container (no pam), and "machinectl shell .host" makes machinectl tell > > > > systemd --system to spawn a login shell on the host (where systemd > > > > --system is using pam_selinux) > > > > > > > > > > > > > > Running machinectl shell .host locally doesn't seem to work: > > > > > $ machinectl shell .host > > > > > Failed to get shell PTY: Access denied > > > > > > > > Probably SELinux blocking then? > > > > > > > > $ id -Z > > > > wheel.id:wheel.role:wheel.subj:s0 > > > > $ machinectl shell .host > > > > AUTHENTICATING FOR org.
Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 03:50:02PM +0200, Dominick Grift wrote: > On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote: > > On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote: > > > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote: > > > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote: > > > > > pam_selinux requirements are generally pretty simple: its used to > > > > > associate a context with a login shell. > > > > > > > > > > With systemd things have becomes a bit more complicated. > > > > > > > > > > systemd uses pam_selinux to associate a context with both a login > > > > > shell (via container-shell@.service) as well as with a systemd --user > > > > > instance. > > > > > > > > > > Ideally one would not associate a login shell context with a systemd > > > > > --user instance because a systemd --user instance needs permissions > > > > > that do not make sense for a login shell to have. > > > > > > > > > > I am not aware of any way to make pam_selinux associate a context > > > > > based on variable like for example: if its a login shell then > > > > > associate this context , and if its a systemd --user instance then > > > > > associate that context > > > > > > > > > > This is an issue for me currently because if users are allowed to > > > > > "host-shell" (machinectl shell .host) then they are able to open a > > > > > shell with the context of the systemd --user instance and escape > > > > > their shell restrictions > > > > > > > > > > For now I can just block host-shell access with polkit but I am > > > > > trying to figure out what it would take to address this challenge > > > > > with pam_selinux > > > > > > > > The logic for determining a security context from pam_selinux (using > > > > libselinux get_ordered_context_with_level) can take the source/from > > > > context (i.e. the context in which the caller of pam_selinux is running > > > > ) into account as a factor in selecting which context to use, since it > > > > checks reachability (transition permission) as part of > > > > security_compute_user(). So that's a possible approach if you can > > > > distinguish what contexts are reachable for systemd --user vs login > > > > daemons. > > > > > > The challenge here is that the source/from context is the same whether > > > systemd --system spawns a login shell on behalf of a login user or > > > whether systemd --system spawns a systemd --user instance on behalf of a > > > login user > > > > > > > > > > > What SELinux permissions are required to host-shell? Can you block > > > > that via SELinux policy rather than just polkit? > > > > > > Might be possible but probably tricky. Not sure what it would take. > > > > > > machinectl shell can also be used to spawn a shell in a container and > > > this doesnt use pam_selinux, only machinectl shell .host makes systemd > > > --system use pam_selinux to determine the pam characteristics to > > > associate with the login shell on the host for the user > > > > > > So "machinectl shell $container" makes machinectl itself a shell in > > > $container (no pam), and "machinectl shell .host" makes machinectl tell > > > systemd --system to spawn a login shell on the host (where systemd > > > --system is using pam_selinux) > > > > > > > > > > > Running machinectl shell .host locally doesn't seem to work: > > > > $ machinectl shell .host > > > > Failed to get shell PTY: Access denied > > > > > > Probably SELinux blocking then? > > > > > > $ id -Z > > > wheel.id:wheel.role:wheel.subj:s0 > > > $ machinectl shell .host > > > AUTHENTICATING FOR org.freedesktop.machine1.host-shell === > > > Authentication is required to acquire a shell on the local host. > > > Authenticating as: kcinimod > > > Password: > > > AUTHENTICATION COMPLETE === > > > Connected to the local host. Press ^] three times within 1s to exit > > > session > > > # journalctl -rb > > > sh: journalctl: command not found > > > # bash > > > # journalctl -rb | grep de
Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 03:30:47PM +0200, Dominick Grift wrote:
> On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote:
> > On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote:
> > > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote:
> > > > pam_selinux requirements are generally pretty simple: its used to
> > > > associate a context with a login shell.
> > > >
> > > > With systemd things have becomes a bit more complicated.
> > > >
> > > > systemd uses pam_selinux to associate a context with both a login
> > > > shell (via container-shell@.service) as well as with a systemd --user
> > > > instance.
> > > >
> > > > Ideally one would not associate a login shell context with a systemd
> > > > --user instance because a systemd --user instance needs permissions
> > > > that do not make sense for a login shell to have.
> > > >
> > > > I am not aware of any way to make pam_selinux associate a context
> > > > based on variable like for example: if its a login shell then
> > > > associate this context , and if its a systemd --user instance then
> > > > associate that context
> > > >
> > > > This is an issue for me currently because if users are allowed to
> > > > "host-shell" (machinectl shell .host) then they are able to open a
> > > > shell with the context of the systemd --user instance and escape
> > > > their shell restrictions
> > > >
> > > > For now I can just block host-shell access with polkit but I am
> > > > trying to figure out what it would take to address this challenge
> > > > with pam_selinux
> > >
> > > The logic for determining a security context from pam_selinux (using
> > > libselinux get_ordered_context_with_level) can take the source/from
> > > context (i.e. the context in which the caller of pam_selinux is running
> > > ) into account as a factor in selecting which context to use, since it
> > > checks reachability (transition permission) as part of
> > > security_compute_user(). So that's a possible approach if you can
> > > distinguish what contexts are reachable for systemd --user vs login
> > > daemons.
> >
> > The challenge here is that the source/from context is the same whether
> > systemd --system spawns a login shell on behalf of a login user or whether
> > systemd --system spawns a systemd --user instance on behalf of a login user
> >
> > >
> > > What SELinux permissions are required to host-shell? Can you block
> > > that via SELinux policy rather than just polkit?
> >
> > Might be possible but probably tricky. Not sure what it would take.
> >
> > machinectl shell can also be used to spawn a shell in a container and this
> > doesnt use pam_selinux, only machinectl shell .host makes systemd --system
> > use pam_selinux to determine the pam characteristics to associate with the
> > login shell on the host for the user
> >
> > So "machinectl shell $container" makes machinectl itself a shell in
> > $container (no pam), and "machinectl shell .host" makes machinectl tell
> > systemd --system to spawn a login shell on the host (where systemd --system
> > is using pam_selinux)
> >
> > >
> > > Running machinectl shell .host locally doesn't seem to work:
> > > $ machinectl shell .host
> > > Failed to get shell PTY: Access denied
> >
> > Probably SELinux blocking then?
> >
> > $ id -Z
> > wheel.id:wheel.role:wheel.subj:s0
> > $ machinectl shell .host
> > AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
> > Authentication is required to acquire a shell on the local host.
> > Authenticating as: kcinimod
> > Password:
> > AUTHENTICATION COMPLETE ===
> > Connected to the local host. Press ^] three times within 1s to exit session
> > # journalctl -rb
> > sh: journalctl: command not found
> > # bash
> > # journalctl -rb | grep denied | head -n 1
> > Sep 07 15:14:29 julius audit[1983]: AVC avc: denied { getattr } for
> > pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183
> > scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0
> > tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
> > # ps auxZ | grep sysadm_systemd.subj
> > sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2 0.0 14452 4500
> > pts
Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 03:22:42PM +0200, Dominick Grift wrote:
> On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote:
> > On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote:
> > > pam_selinux requirements are generally pretty simple: its used to
> > > associate a context with a login shell.
> > >
> > > With systemd things have becomes a bit more complicated.
> > >
> > > systemd uses pam_selinux to associate a context with both a login
> > > shell (via container-shell@.service) as well as with a systemd --user
> > > instance.
> > >
> > > Ideally one would not associate a login shell context with a systemd
> > > --user instance because a systemd --user instance needs permissions
> > > that do not make sense for a login shell to have.
> > >
> > > I am not aware of any way to make pam_selinux associate a context
> > > based on variable like for example: if its a login shell then
> > > associate this context , and if its a systemd --user instance then
> > > associate that context
> > >
> > > This is an issue for me currently because if users are allowed to
> > > "host-shell" (machinectl shell .host) then they are able to open a
> > > shell with the context of the systemd --user instance and escape
> > > their shell restrictions
> > >
> > > For now I can just block host-shell access with polkit but I am
> > > trying to figure out what it would take to address this challenge
> > > with pam_selinux
> >
> > The logic for determining a security context from pam_selinux (using
> > libselinux get_ordered_context_with_level) can take the source/from
> > context (i.e. the context in which the caller of pam_selinux is running
> > ) into account as a factor in selecting which context to use, since it
> > checks reachability (transition permission) as part of
> > security_compute_user(). So that's a possible approach if you can
> > distinguish what contexts are reachable for systemd --user vs login
> > daemons.
>
> The challenge here is that the source/from context is the same whether
> systemd --system spawns a login shell on behalf of a login user or whether
> systemd --system spawns a systemd --user instance on behalf of a login user
>
> >
> > What SELinux permissions are required to host-shell? Can you block
> > that via SELinux policy rather than just polkit?
>
> Might be possible but probably tricky. Not sure what it would take.
>
> machinectl shell can also be used to spawn a shell in a container and this
> doesnt use pam_selinux, only machinectl shell .host makes systemd --system
> use pam_selinux to determine the pam characteristics to associate with the
> login shell on the host for the user
>
> So "machinectl shell $container" makes machinectl itself a shell in
> $container (no pam), and "machinectl shell .host" makes machinectl tell
> systemd --system to spawn a login shell on the host (where systemd --system
> is using pam_selinux)
>
> >
> > Running machinectl shell .host locally doesn't seem to work:
> > $ machinectl shell .host
> > Failed to get shell PTY: Access denied
>
> Probably SELinux blocking then?
>
> $ id -Z
> wheel.id:wheel.role:wheel.subj:s0
> $ machinectl shell .host
> AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
> Authentication is required to acquire a shell on the local host.
> Authenticating as: kcinimod
> Password:
> AUTHENTICATION COMPLETE ===
> Connected to the local host. Press ^] three times within 1s to exit session
> # journalctl -rb
> sh: journalctl: command not found
> # bash
> # journalctl -rb | grep denied | head -n 1
> Sep 07 15:14:29 julius audit[1983]: AVC avc: denied { getattr } for
> pid=1983 comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183
> scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0
> tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
> # ps auxZ | grep sysadm_systemd.subj
> sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2 0.0 14452 4500
> pts/4 Ss 15:14 0:00 -bin/sh
> sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2 0.0 82036 7956 ?
> Ss 15:14 0:00 /usr/lib/systemd/systemd --user
>
> So systemd --system runs -bin/sh using its pam_selinux which tells it to
> associate "sysadm_systemd.subj" with the login process, but that type is for
> the systemd --user instance of this user
> then there is an automatic transition from sysadm_systemd.subj to sysadm.subj
> on cmd.shell.cmd_fi
Re: pam_selinux and systemd
On Thu, Sep 07, 2017 at 08:55:23AM -0400, Stephen Smalley wrote:
> On Thu, 2017-09-07 at 11:05 +0200, Dominick Grift wrote:
> > pam_selinux requirements are generally pretty simple: its used to
> > associate a context with a login shell.
> >
> > With systemd things have becomes a bit more complicated.
> >
> > systemd uses pam_selinux to associate a context with both a login
> > shell (via container-shell@.service) as well as with a systemd --user
> > instance.
> >
> > Ideally one would not associate a login shell context with a systemd
> > --user instance because a systemd --user instance needs permissions
> > that do not make sense for a login shell to have.
> >
> > I am not aware of any way to make pam_selinux associate a context
> > based on variable like for example: if its a login shell then
> > associate this context , and if its a systemd --user instance then
> > associate that context
> >
> > This is an issue for me currently because if users are allowed to
> > "host-shell" (machinectl shell .host) then they are able to open a
> > shell with the context of the systemd --user instance and escape
> > their shell restrictions
> >
> > For now I can just block host-shell access with polkit but I am
> > trying to figure out what it would take to address this challenge
> > with pam_selinux
>
> The logic for determining a security context from pam_selinux (using
> libselinux get_ordered_context_with_level) can take the source/from
> context (i.e. the context in which the caller of pam_selinux is running
> ) into account as a factor in selecting which context to use, since it
> checks reachability (transition permission) as part of
> security_compute_user(). So that's a possible approach if you can
> distinguish what contexts are reachable for systemd --user vs login
> daemons.
The challenge here is that the source/from context is the same whether systemd
--system spawns a login shell on behalf of a login user or whether systemd
--system spawns a systemd --user instance on behalf of a login user
>
> What SELinux permissions are required to host-shell? Can you block
> that via SELinux policy rather than just polkit?
Might be possible but probably tricky. Not sure what it would take.
machinectl shell can also be used to spawn a shell in a container and this
doesnt use pam_selinux, only machinectl shell .host makes systemd --system use
pam_selinux to determine the pam characteristics to associate with the login
shell on the host for the user
So "machinectl shell $container" makes machinectl itself a shell in $container
(no pam), and "machinectl shell .host" makes machinectl tell systemd --system
to spawn a login shell on the host (where systemd --system is using pam_selinux)
>
> Running machinectl shell .host locally doesn't seem to work:
> $ machinectl shell .host
> Failed to get shell PTY: Access denied
Probably SELinux blocking then?
$ id -Z
wheel.id:wheel.role:wheel.subj:s0
$ machinectl shell .host
AUTHENTICATING FOR org.freedesktop.machine1.host-shell ===
Authentication is required to acquire a shell on the local host.
Authenticating as: kcinimod
Password:
AUTHENTICATION COMPLETE ===
Connected to the local host. Press ^] three times within 1s to exit session
# journalctl -rb
sh: journalctl: command not found
# bash
# journalctl -rb | grep denied | head -n 1
Sep 07 15:14:29 julius audit[1983]: AVC avc: denied { getattr } for pid=1983
comm="sh" path="/usr/bin/journalctl" dev="dm-1" ino=2756183
scontext=sysadm.id:sysadm.role:sysadm_systemd.subj:s0
tcontext=sys.id:sys.role:journalctl.cmd_file:s0 tclass=file permissive=0
# ps auxZ | grep sysadm_systemd.subj
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1983 0.2 0.0 14452 4500
pts/4 Ss 15:14 0:00 -bin/sh
sysadm.id:sysadm.role:sysadm_systemd.subj:s0 root 1988 0.2 0.0 82036 7956 ?
Ss 15:14 0:00 /usr/lib/systemd/systemd --user
So systemd --system runs -bin/sh using its pam_selinux which tells it to
associate "sysadm_systemd.subj" with the login process, but that type is for
the systemd --user instance of this user
then there is an automatic transition from sysadm_systemd.subj to sysadm.subj
on cmd.shell.cmd_file that eventually makes the transition work when manually
running bash
I put in that auto type transition (sysadm_systemd.subj > (cmd.shell.cmd_file)
-> sysadm.subj) not realizing that the shell initially ends up with
sysadm_systemd.subj via pam_selinux
So i should remove that auto type transition as well since i shouldnt end up in
sysadm_systemd.subj in the first place
>
> Ideally, I'd like to get rid of security_compute_user() entirely, take
> the logic for determining user context entirel
conditional role and range transitions?
I was just reminded of the fact that role and range transitions cannot be conditional in kernel policy. Is this technically impossible? Why can type transitions be conditional in kernel policy but not role and range transitions? -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
pam_selinux and systemd
pam_selinux requirements are generally pretty simple: its used to associate a context with a login shell. With systemd things have becomes a bit more complicated. systemd uses pam_selinux to associate a context with both a login shell (via container-shell@.service) as well as with a systemd --user instance. Ideally one would not associate a login shell context with a systemd --user instance because a systemd --user instance needs permissions that do not make sense for a login shell to have. I am not aware of any way to make pam_selinux associate a context based on variable like for example: if its a login shell then associate this context , and if its a systemd --user instance then associate that context This is an issue for me currently because if users are allowed to "host-shell" (machinectl shell .host) then they are able to open a shell with the context of the systemd --user instance and escape their shell restrictions For now I can just block host-shell access with polkit but I am trying to figure out what it would take to address this challenge with pam_selinux -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: sysfs symlinks in genfscon
On Tue, Aug 29, 2017 at 08:56:47AM -0400, Stephen Smalley wrote: > On Tue, 2017-08-29 at 08:54 -0400, Stephen Smalley wrote: > > On Mon, 2017-08-28 at 14:58 -0700, Jeffrey Vander Stoep via Selinux > > wrote: > > > Genfs_contexts does not label symlinks in sysfs, instead it leaves > > > them with the default “sysfs” label. Is this a bug? > > > > We excluded symlinks from genfscon labeling back when only proc was > > using genfscon for per-file labeling and we encountered a > > compatibility > > problem when /proc/net was moved to /proc/self/net for network > > namespaces (see commit cited below). Suddenly applications were > > getting > > proc_net_t:lnk_file read denials when accessing /proc/net because > > existing policies only allowed proc_t:lnk_file read and > > proc_net_t:dir/file read, so new kernel + old policy broke userspace, > > which is not allowed by Linus. At the time, I couldn't see a use > > case > > where we would need to support per-file labeling of symlinks in proc, > > since the only meaningful operation on a proc symlink is > > read/getattr. > > The real access controls are to the individual directories/files, not > > the symlinks. > > > > Do you truly need per-file labeling of symlinks in sysfs? What's the > > use case? I guess it is an inconsistency between the support for > > sysfs > > labeling via setxattr vs genfscon, but there are likely other more > > significant inconsistencies due to the support for pathname regexes > > in > > file_contexts versus pathname prefixes in genfscon, e.g. see > > https://github.com/SELinuxProject/selinux-kernel/issues/29 > > > > That said, I agree it is an ugly hack and should likely be removed if > > it doesn't cause compatibility problems (we'd need to test on RHEL > > 6/7 > > at least). > > I guess we should probably wrap the change with a policy capability so > that it can be conditionally enabled by new policies and then we don't > have to worry about any compatibility problems with old policies. A policy capability would be nice. I would be interested in reading more about the use-case for this as well. > > > > > Have you measured to see the impact of switching from setxattr to > > genfscon for sysfs labeling? > > > > commit ea6b184f7d521a503ecab71feca6e4057562252b > > Author: Stephen Smalley <s...@tycho.nsa.gov> > > Date: Mon Sep 22 15:41:19 2008 -0400 > > > > selinux: use default proc sid on symlinks > > > > As we are not concerned with fine-grained control over reading of > > symlinks in proc, always use the default proc SID for all proc > > symlinks. > > This should help avoid permission issues upon changes to the proc > > tree > > as in the /proc/net -> /proc/self/net example. > > This does not alter labeling of symlinks within /proc/pid > > directories. > > ls -Zd /proc/net output before and after the patch should show > > the > > differenc > > e. > > > > Signed-off-by: Stephen D. Smalley <s...@tycho.nsa.gov> > > Signed-off-by: James Morris <jmor...@namei.org> -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: ANN: SELinux userspace release 20170804 / 2.7
ple usage is checkpolicy -M -C -b policy.N -o > policy.cil and checkpolicy -M -F -b policy.N -o policy.conf. There is > also now a secil2conf program that can generate policy.conf from CIL, > e.g. secil2conf -o policy.conf policy.cil. > > * Attribute generation and expansion has changed in several ways in > order to address kernel runtime performance issues that occur when > types have many attributes assigned to them while ensuring preservation > of attributes where desired. Binary module to CIL conversion now > ensures that duplicate attributes are not generated for the same type > set. secilc now supports -G and -X options to force expansion of > automatically generated attributes (-G) and/or attributes that have > fewer than a specified number of types (-X number). secilc will also > now more aggressively expand attributes based on whether they will > actually be used by the kernel, are needed for debugging denials by > audit2allow/why, or are needed for neverallow checking of binary > policies (in Android). New statements are supported in policy.conf > (expandattribute) and in CIL (expandtypeattribute) to support > specifying in source policy that specific attributes should always be > expanded or never be expanded in order to override the default > behaviors in checkpolicy and secilc. This statement (expandtypeattribute) should probably be documented in the secilc docs: https://github.com/SELinuxProject/selinux/tree/master/secilc/docs > > * checkpolicy/checkmodule now treats it as an error if a type is > declared as an attribute or vice versa in a require block. Such > mismatches between declarations and require statements are an error in > policy and should be corrected in policy; refpolicy master should > already be fixed. > > * A change to libsepol-internal data structures breaks the build of > setools4. This is fixed by setools4 commit > 743d2a0eaaae7d99302dd3099549ca7ad868eab on the master branch. The > change was to align the libsepol structures with the kernel in order to > allow direct comparison of libsepol-generated policy files against > /sys/fs/selinux/policy after normalizing them through checkpolicy. > > * audit2why now understands type bounds failures and reports them as > such, although it does not yet provide detailed reporting. Detailed > bounds violation reporting can be obtained already by enabling expand- > check=1 in semanage.conf or by running semodule_expand (without -a) at > policy validation time. > > * libsemanage now saves the linked policy and skips re-linking > whenever possible. This significantly improves the performance and > memory overhead of semanage commands that do not affect policy modules > (setting booleans and adding, deleting, or modifying local context > mappings). Previously, libsemanage only skipped re-linking when setting > booleans as a special case, but this was found to have a bug that could > yield duplicate object context entries (e.g. portcon) in policy. That > optimization was therefore reverted and replaced with this one, which > both fixes the bug and generalizes the optimization beyond just setting > booleans. The change does bring an associated storage cost, primarily > storing an extra copy of the kernel policy file (if a concern, this > could be made optional but it seems well worth it). The first semanage > or setsebool -P command run with the new libsemanage will not > demonstrate any improvement due to needing to generate the linked > policy for the first time, but subsequent commands will leverage the > saved linked policy. > > * libsemanage no longer depends on ustr. > > * libselinux/utils Makefile now uses SBINDIR instead of USRBINDIR. > > * mcstrans/utils Makefile now uses SBINDIR instead of BINDIR. > > * Some packages (libselinux, checkpolicy, selinux-python, > semodule-utils and mcstrans) require LIBSEPOLA to be set to the > absolute path to libsepol.a when building with DESTDIR set. > > * policycoreutils make install no longer creates a symlink from > /usr/sbin/load_policy to /sbin/load_policy. > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute
On Wed, Aug 02, 2017 at 06:35:00PM +0200, Dominick Grift wrote:
> On Wed, Aug 02, 2017 at 04:41:00PM +0100, Carlos Rodrigues wrote:
> > Hi,
> >
> > I don't know if this a too basic question to ask here, or the proper
> > place, but here it goes:
> >
> > I've been chasing some weird (to me) behavior with the targeted policy
> > on a VM running nginx as a reverse proxy. What happens is that the
> > "httpd_can_network_connect" boolean needs to be enabled for nginx to
> > be able to reach its upstream servers. So far, so good.
> >
> > However, if the upsteam server happens to be listening in one of the
> > "http_port_t" ports, "httpd_can_network_connect" isn't needed because
> > the "httpd_graceful_shutdown" (default enabled) provides the required
> > allow rule ("name_connect").
> >
> > This seems strange to me. Is this supposed to be like this? I would
> > expect nginx to be totally unable to establish outbound connections by
> > default.
> >
> > Best regards,
> >
> > Carlos Rodrigues
> >
> > PS: I just spent a few hours on this, wondering why one machine needed
> > "httpd_can_network_connect" and another did not. I guess I've mostly
> > been setting up reverse proxies for "http_port_t" upstreams on CentOS
> > all this time...
>
> I think the "httpd_graceful_shutdown" is an apache thing (probably for
> "apachectl graceful-stop"). However I cannot reproduce this behavior with
> httpd-2.4.27-4.fc27.
Also "httpd_can_network_connect" grants broader network access to httpd
By the way: refpolicy questions should be directed to the refpolicy maillist:
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=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute
On Wed, Aug 02, 2017 at 02:59:34PM -0400, Stephen Smalley wrote:
> On Wed, 2017-08-02 at 18:35 +0200, Dominick Grift wrote:
> > On Wed, Aug 02, 2017 at 04:41:00PM +0100, Carlos Rodrigues wrote:
> > > Hi,
> > >
> > > I don't know if this a too basic question to ask here, or the
> > > proper
> > > place, but here it goes:
> > >
> > > I've been chasing some weird (to me) behavior with the targeted
> > > policy
> > > on a VM running nginx as a reverse proxy. What happens is that the
> > > "httpd_can_network_connect" boolean needs to be enabled for nginx
> > > to
> > > be able to reach its upstream servers. So far, so good.
> > >
> > > However, if the upsteam server happens to be listening in one of
> > > the
> > > "http_port_t" ports, "httpd_can_network_connect" isn't needed
> > > because
> > > the "httpd_graceful_shutdown" (default enabled) provides the
> > > required
> > > allow rule ("name_connect").
> > >
> > > This seems strange to me. Is this supposed to be like this? I would
> > > expect nginx to be totally unable to establish outbound connections
> > > by
> > > default.
> > >
> > > Best regards,
> > >
> > > Carlos Rodrigues
> > >
> > > PS: I just spent a few hours on this, wondering why one machine
> > > needed
> > > "httpd_can_network_connect" and another did not. I guess I've
> > > mostly
> > > been setting up reverse proxies for "http_port_t" upstreams on
> > > CentOS
> > > all this time...
> >
> > I think the "httpd_graceful_shutdown" is an apache thing (probably
> > for "apachectl graceful-stop"). However I cannot reproduce this
> > behavior with httpd-2.4.27-4.fc27.
>
> Hmm...neither can I; seemingly apachectl graceful-stop works without
> requiring this boolean anymore. So maybe it can be disabled by default
> and removed at some point in Fedora policy?
>
Would be nice if we would be able to confirm this with the apache maintainer
before jumping to conclusions.
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: httpd_graceful_shutdown makes httpd_can_network_connect mostly mute
On Wed, Aug 02, 2017 at 04:41:00PM +0100, Carlos Rodrigues wrote:
> Hi,
>
> I don't know if this a too basic question to ask here, or the proper
> place, but here it goes:
>
> I've been chasing some weird (to me) behavior with the targeted policy
> on a VM running nginx as a reverse proxy. What happens is that the
> "httpd_can_network_connect" boolean needs to be enabled for nginx to
> be able to reach its upstream servers. So far, so good.
>
> However, if the upsteam server happens to be listening in one of the
> "http_port_t" ports, "httpd_can_network_connect" isn't needed because
> the "httpd_graceful_shutdown" (default enabled) provides the required
> allow rule ("name_connect").
>
> This seems strange to me. Is this supposed to be like this? I would
> expect nginx to be totally unable to establish outbound connections by
> default.
>
> Best regards,
>
> Carlos Rodrigues
>
> PS: I just spent a few hours on this, wondering why one machine needed
> "httpd_can_network_connect" and another did not. I guess I've mostly
> been setting up reverse proxies for "http_port_t" upstreams on CentOS
> all this time...
I think the "httpd_graceful_shutdown" is an apache thing (probably for
"apachectl graceful-stop"). However I cannot reproduce this behavior with
httpd-2.4.27-4.fc27.
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: [PATCH] selinux: Generalize support for NNP/nosuid SELinux domain transitions
On Thu, Jul 20, 2017 at 09:04:18AM -0400, Stephen Smalley wrote: > On Wed, 2017-07-19 at 21:17 -0400, Chris PeBenito wrote: > > On 07/19/2017 05:31 PM, Dominick Grift wrote: > > > On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote: > > > > On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote: > > > > > On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote: > > > > > > On 07/18/2017 05:26 PM, Paul Moore wrote: > > > > > > > On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley <sds@tycho > > > > > > > .nsa.gov> wrote: > > > > > > > > On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: > > > > > > > > > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: > > > > > > > > > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <jason@ > > > > > > > > > > perfinion.com> > > > > > > > > > > wrote: > > > > > > > > > > > > > > ... > > > > > > > > > > > > > > > > > > Why do we want to disallow type-bounds to work even > > > > > > > > > > > with the > > > > > > > > > > > capability? > > > > > > > > > > > it seems sensible to me to allow typebounds to > > > > > > > > > > > transition even in > > > > > > > > > > > the > > > > > > > > > > > future. If we do then we probably dont need the > > > > > > > > > > > policycap which > > > > > > > > > > > seems > > > > > > > > > > > less complicated. > > > > > > > > > > > > > > > > > > > > The suggestion to continue to support bounded domain > > > > > > > > > > transitions > > > > > > > > > > seems > > > > > > > > > > reasonable to me, although we would need to worry > > > > > > > > > > about which check > > > > > > > > > > to > > > > > > > > > > do first (bounded transition or > > > > > > > > > > process:nnp_nosuid_transition), and > > > > > > > > > > how to limit the auditing/reporting so admins are > > > > > > > > > > confused by the > > > > > > > > > > first check failing, yet the transition still taking > > > > > > > > > > place. None > > > > > > > > > > of > > > > > > > > > > these are unsolvable problems, but it will likely > > > > > > > > > > need a bit more > > > > > > > > > > work. > > > > > > > > > > > > > > > > > > > > I'm sure Stephen has some thoughts on this as well. > > > > > > > > > > > > > > > > > > Others (e.g. Dominick) seemed to take the opposite view > > > > > > > > > on the > > > > > > > > > earlier > > > > > > > > > RFC discussion, i.e. that we should only check the new > > > > > > > > > permission if > > > > > > > > > the capability is enabled. I specifically raised that > > > > > > > > > as a question > > > > > > > > > there. > > > > > > > > > > > > > > > > > > I'm willing to change it to fallback to checking for a > > > > > > > > > bounded type, > > > > > > > > > but that will mean two audit messages (I don't think we > > > > > > > > > can just hide > > > > > > > > > one of them) when neither is allowed. That said, it is > > > > > > > > > unlikely to > > > > > > > > > cause much confusion in practice because users > > > > > > > > > typically only look > > > > > > > > > for > > > > > > > > > and pay attention to AVC messages, and anyone using > > > > > > > > > audit2allow will > > > > > > > > > just end up allowing the permission, n
[SUSPECTED SPAM] [SUSPICIOUS MESSAGE] Re: [PATCH] selinux: Generalize support for NNP/nosuid SELinux domain transitions
On Wed, Jul 19, 2017 at 10:49:46PM +0200, Dominick Grift wrote: > On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote: > > On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote: > > > On 07/18/2017 05:26 PM, Paul Moore wrote: > > > > On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley <s...@tycho.nsa.gov> > > > > wrote: > > > > > On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: > > > > > > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: > > > > > > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman > > > > > > > <ja...@perfinion.com> > > > > > > > wrote: > > > > > > > > ... > > > > > > > > > > > > Why do we want to disallow type-bounds to work even with the > > > > > > > > capability? > > > > > > > > it seems sensible to me to allow typebounds to transition even > > > > > > > > in > > > > > > > > the > > > > > > > > future. If we do then we probably dont need the policycap which > > > > > > > > seems > > > > > > > > less complicated. > > > > > > > > > > > > > > The suggestion to continue to support bounded domain transitions > > > > > > > seems > > > > > > > reasonable to me, although we would need to worry about which > > > > > > > check > > > > > > > to > > > > > > > do first (bounded transition or process:nnp_nosuid_transition), > > > > > > > and > > > > > > > how to limit the auditing/reporting so admins are confused by the > > > > > > > first check failing, yet the transition still taking place. None > > > > > > > of > > > > > > > these are unsolvable problems, but it will likely need a bit more > > > > > > > work. > > > > > > > > > > > > > > I'm sure Stephen has some thoughts on this as well. > > > > > > > > > > > > Others (e.g. Dominick) seemed to take the opposite view on the > > > > > > earlier > > > > > > RFC discussion, i.e. that we should only check the new permission if > > > > > > the capability is enabled. I specifically raised that as a question > > > > > > there. > > > > > > > > > > > > I'm willing to change it to fallback to checking for a bounded type, > > > > > > but that will mean two audit messages (I don't think we can just > > > > > > hide > > > > > > one of them) when neither is allowed. That said, it is unlikely to > > > > > > cause much confusion in practice because users typically only look > > > > > > for > > > > > > and pay attention to AVC messages, and anyone using audit2allow will > > > > > > just end up allowing the permission, not the bounds. > > > > > > > > > > As Jason noted, if we fallback to checking for a bounded type, then we > > > > > don't strictly need a policy capability for it. > > > > > > > > It seems as though Dominick is okay with the fallback, what do the > > > > rest of the policy folks think about that approach? > > > > I am okay with the faillback > > > > > > > > > > I'm of the opinion that changes which don't require a new policy > > > > capability are slightly more favorable, but since one of the goals > > > > with this change is to make policy development easier, I want to make > > > > sure we are actually doing that. It would appear we are, but a few > > > > explicit nods from the policy folks would be nice to see. > > > > > > With my coder hat on, I can see the value of having the existing behavior > > > be > > > available for anyone who currently uses it, so it makes sense. > > > > I agree, its only that I believe that no one is using it because it is > > impractical (except for mod_selinux users, and people that currently use > > type_bounds to deal with nosuid),, mainly because the nnp flag is inherited. > > The only scenario currently where, I believe, type_bounds might be prefered > > is containers since container process types do not change and the > > inheritance aspect is not mu
[SUSPECTED SPAM] [SUSPICIOUS MESSAGE] Re: [PATCH] selinux: Generalize support for NNP/nosuid SELinux domain transitions
On Wed, Jul 19, 2017 at 09:12:33AM +0200, Dominick Grift wrote: > On Tue, Jul 18, 2017 at 09:07:45PM -0400, Chris PeBenito wrote: > > On 07/18/2017 05:26 PM, Paul Moore wrote: > > > On Tue, Jul 18, 2017 at 3:20 PM, Stephen Smalley <s...@tycho.nsa.gov> > > > wrote: > > > > On Tue, 2017-07-18 at 09:17 -0400, Stephen Smalley wrote: > > > > > On Mon, 2017-07-17 at 15:54 -0400, Paul Moore wrote: > > > > > > On Sun, Jul 16, 2017 at 11:15 AM, Jason Zaman <ja...@perfinion.com> > > > > > > wrote: > > > > > > ... > > > > > > > > > > Why do we want to disallow type-bounds to work even with the > > > > > > > capability? > > > > > > > it seems sensible to me to allow typebounds to transition even in > > > > > > > the > > > > > > > future. If we do then we probably dont need the policycap which > > > > > > > seems > > > > > > > less complicated. > > > > > > > > > > > > The suggestion to continue to support bounded domain transitions > > > > > > seems > > > > > > reasonable to me, although we would need to worry about which check > > > > > > to > > > > > > do first (bounded transition or process:nnp_nosuid_transition), and > > > > > > how to limit the auditing/reporting so admins are confused by the > > > > > > first check failing, yet the transition still taking place. None > > > > > > of > > > > > > these are unsolvable problems, but it will likely need a bit more > > > > > > work. > > > > > > > > > > > > I'm sure Stephen has some thoughts on this as well. > > > > > > > > > > Others (e.g. Dominick) seemed to take the opposite view on the > > > > > earlier > > > > > RFC discussion, i.e. that we should only check the new permission if > > > > > the capability is enabled. I specifically raised that as a question > > > > > there. > > > > > > > > > > I'm willing to change it to fallback to checking for a bounded type, > > > > > but that will mean two audit messages (I don't think we can just hide > > > > > one of them) when neither is allowed. That said, it is unlikely to > > > > > cause much confusion in practice because users typically only look > > > > > for > > > > > and pay attention to AVC messages, and anyone using audit2allow will > > > > > just end up allowing the permission, not the bounds. > > > > > > > > As Jason noted, if we fallback to checking for a bounded type, then we > > > > don't strictly need a policy capability for it. > > > > > > It seems as though Dominick is okay with the fallback, what do the > > > rest of the policy folks think about that approach? > > I am okay with the faillback > > > > > > > I'm of the opinion that changes which don't require a new policy > > > capability are slightly more favorable, but since one of the goals > > > with this change is to make policy development easier, I want to make > > > sure we are actually doing that. It would appear we are, but a few > > > explicit nods from the policy folks would be nice to see. > > > > With my coder hat on, I can see the value of having the existing behavior be > > available for anyone who currently uses it, so it makes sense. > > I agree, its only that I believe that no one is using it because it is > impractical (except for mod_selinux users, and people that currently use > type_bounds to deal with nosuid),, mainly because the nnp flag is inherited. > The only scenario currently where, I believe, type_bounds might be prefered > is containers since container process types do not change and the inheritance > aspect is not much of a problem. > > > > > With my policy hat on, I don't have an opinion on a fallback. What I do > > know is I don't like typebounds, avoid it as much as possible, and strongly > > prefer it not be forced on me. There are no typebounds in refpolicy. > > > > In fact, I think NNP should not affecting SELinux at all as NNP is > > discretionary and SELinux is mandatory. NNP makes sense where you start out > > with lots of privileges and have to shed them, (i.e. the Linux > > DAC/capabilities perspective) whereas you have no privileges in SELinux &
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Thu, Jul 13, 2017 at 07:55:14PM -0400, Chris PeBenito wrote: > On 07/13/2017 04:11 PM, Dominick Grift wrote: > > On Thu, Jul 13, 2017 at 03:59:29PM -0400, Stephen Smalley wrote: > > > On Thu, 2017-07-13 at 21:43 +0200, Dominick Grift wrote: > > > > On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote: > > > > > On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote: > > > > > > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote: > > > > > > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley > > > > > > > wrote: > > > > > > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote: > > > > > > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley > > > > > > > > > wrote: > > > > > > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote: > > > > > > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote: > > > > > > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley > > > > > > > > > > > @tycho > > > > > > > > > > > > .nsa > > > > > > > > > > > > .gov > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote: > > > > > > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen > > > > > > > > > > > > > > > Smalley > > > > > > > > > > > > > > @tyc > > > > > > > > > > > > > > > ho.n > > > > > > > > > > > > > > > sa > > > > > > > > > > > > > > > .gov > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen > > > > > > > > > > > > > > > > > Smalley > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @tyc > > > > > > > > > > > > > > > > > ho > > > > > > > > > > > > > > > > > .nsa > > > > > > > > > > > > > > > > > .gov> > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > While I think splitting the NNP/nosuid > > > > > > > > > > > > > > > transition > > > > > > > > > > > > > > > restrictions > > > > > > > > > > > > > > > might > > > > > > > > > > > > > > > be a good idea under the new policy capability, > > > > > > > > > > > > > > > I'm > > > > > > > > > > > > > > > not > > > > > > > > > > > > > > > sure > > > > > > > > > > > > > > > it > > > > > > > > > > > > > > > is > > > > > > > > > > > > > > > worth the cost of a "process2" object class. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > With that in mind, let's do two things with > > > > > > > > > > > > > > > this > > > > > > > > > > > > > > > patch: > > >
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Thu, Jul 13, 2017 at 03:59:29PM -0400, Stephen Smalley wrote: > On Thu, 2017-07-13 at 21:43 +0200, Dominick Grift wrote: > > On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote: > > > On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote: > > > > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote: > > > > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley > > > > > wrote: > > > > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote: > > > > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley > > > > > > > wrote: > > > > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote: > > > > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote: > > > > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley > > > > > > > > > @tycho > > > > > > > > > > .nsa > > > > > > > > > > .gov > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito > > > > > > > > > > > wrote: > > > > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote: > > > > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen > > > > > > > > > > > > > Smalley > > > > > > > > > > > > @tyc > > > > > > > > > > > > > ho.n > > > > > > > > > > > > > sa > > > > > > > > > > > > > .gov > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen > > > > > > > > > > > > > > > Smalley > > > > > > > > > > > > > > > > > > > > > > > > > > > > > @tyc > > > > > > > > > > > > > > > ho > > > > > > > > > > > > > > > .nsa > > > > > > > > > > > > > > > .gov> > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > While I think splitting the NNP/nosuid > > > > > > > > > > > > > transition > > > > > > > > > > > > > restrictions > > > > > > > > > > > > > might > > > > > > > > > > > > > be a good idea under the new policy capability, > > > > > > > > > > > > > I'm > > > > > > > > > > > > > not > > > > > > > > > > > > > sure > > > > > > > > > > > > > it > > > > > > > > > > > > > is > > > > > > > > > > > > > worth the cost of a "process2" object class. > > > > > > > > > > > > > > > > > > > > > > > > > > With that in mind, let's do two things with > > > > > > > > > > > > > this > > > > > > > > > > > > > patch: > > > > > > > > > > > > > > > > > > > > > > > > > > * Mention the nosuid restrictions in the patch > > > > > > > > > > > > > description. It > > > > > > > > > > > > > doesn't need much text, but something would be > > > > > > > > > > > > > good > > > > > > > > > > > > > so we > > > > > > > > > > > > > have > > > > > > > > > > > > > documentation in the git log. > > > > > > > > >
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote: > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote: > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote: > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote: > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote: > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote: > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote: > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho > > > > > > > .nsa > > > > > > > .gov > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote: > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote: > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley > > > > > > > > > @tyc > > > > > > > > > > ho.n > > > > > > > > > > sa > > > > > > > > > > .gov > > > > > > > > > > > wrote: > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore > > > > > > > > > > > wrote: > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley > > > > > > > > > > > > > > > > > > > > > > > @tyc > > > > > > > > > > > > ho > > > > > > > > > > > > .nsa > > > > > > > > > > > > .gov> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > While I think splitting the NNP/nosuid transition > > > > > > > > > > restrictions > > > > > > > > > > might > > > > > > > > > > be a good idea under the new policy capability, I'm > > > > > > > > > > not > > > > > > > > > > sure > > > > > > > > > > it > > > > > > > > > > is > > > > > > > > > > worth the cost of a "process2" object class. > > > > > > > > > > > > > > > > > > > > With that in mind, let's do two things with this > > > > > > > > > > patch: > > > > > > > > > > > > > > > > > > > > * Mention the nosuid restrictions in the patch > > > > > > > > > > description. It > > > > > > > > > > doesn't need much text, but something would be good > > > > > > > > > > so we > > > > > > > > > > have > > > > > > > > > > documentation in the git log. > > > > > > > > > > > > > > > > > > > > * Let's pick a new permission name that is not > > > > > > > > > > specific > > > > > > > > > > to > > > > > > > > > > NNP > > > > > > > > > > or > > > > > > > > > > nosuid. IMHO, nnpnosuid_transition is ... less than > > > > > > > > > > good. > > > > > > > > > > Unfortunately, I'm not sure I'm much better at > > > > > > > > > > picking > > > > > > > > > > names; > > > > > > > > > > how > > > > > > > > > > about > > > > > > > > > > "protected_transition"? "restricted_transition"? > > > > > > > > > > "enable_transition"? "override_transition"? > > > > > > > > > > > > > > > > > > I vote for nnp_transition anyway. "No New Privileges" > > > > > > > > > encompasses > > > > > > > > > nosuid in my mind. If the two perms had been separated > > > > > > > > > I > > > > > > > > > would > > > > > > > > > have > &
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Thu, Jul 13, 2017 at 08:16:14PM +0200, Dominick Grift wrote: > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote: > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote: > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote: > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote: > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote: > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <s...@tycho.nsa > > > > > > .gov > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote: > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote: > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tyc > > > > > > > > > ho.n > > > > > > > > > sa > > > > > > > > > .gov > > > > > > > > > > wrote: > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote: > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley > > > > > > > > > > @tyc > > > > > > > > > > > ho > > > > > > > > > > > .nsa > > > > > > > > > > > .gov> > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > While I think splitting the NNP/nosuid transition > > > > > > > > > restrictions > > > > > > > > > might > > > > > > > > > be a good idea under the new policy capability, I'm not > > > > > > > > > sure > > > > > > > > > it > > > > > > > > > is > > > > > > > > > worth the cost of a "process2" object class. > > > > > > > > > > > > > > > > > > With that in mind, let's do two things with this patch: > > > > > > > > > > > > > > > > > > * Mention the nosuid restrictions in the patch > > > > > > > > > description. It > > > > > > > > > doesn't need much text, but something would be good so we > > > > > > > > > have > > > > > > > > > documentation in the git log. > > > > > > > > > > > > > > > > > > * Let's pick a new permission name that is not specific > > > > > > > > > to > > > > > > > > > NNP > > > > > > > > > or > > > > > > > > > nosuid. IMHO, nnpnosuid_transition is ... less than > > > > > > > > > good. > > > > > > > > > Unfortunately, I'm not sure I'm much better at picking > > > > > > > > > names; > > > > > > > > > how > > > > > > > > > about "protected_transition"? "restricted_transition"? > > > > > > > > > "enable_transition"? "override_transition"? > > > > > > > > > > > > > > > > I vote for nnp_transition anyway. "No New Privileges" > > > > > > > > encompasses > > > > > > > > nosuid in my mind. If the two perms had been separated I > > > > > > > > would > > > > > > > > have > > > > > > > > been inclined to allow both every time one of them was > > > > > > > > needed, > > > > > > > > to > > > > > > > > make > > > > > > > > sure no one was surprised by the behavior difference. > > > > > > > > > > > > > > I agree; I'll keep it as nnp_transition and just document it > > > > > > > in > > > > > > > the > > > > > > > patch description. > > > > > > > > > > > > Sorry to be a stubborn about this, but nnp_transition makes > > > > > > little > > > > > > sense for the nosuid restriction. Like it or not, NNP has a > > > > > > concrete > > > > &g
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Thu, Jul 13, 2017 at 09:28:43PM +0200, Dominick Grift wrote: > On Thu, Jul 13, 2017 at 03:29:56PM -0400, Stephen Smalley wrote: > > On Thu, 2017-07-13 at 20:16 +0200, Dominick Grift wrote: > > > On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote: > > > > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote: > > > > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote: > > > > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote: > > > > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote: > > > > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <sds@tycho > > > > > > > > .nsa > > > > > > > > .gov > > > > > > > > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote: > > > > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote: > > > > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley > > > > > > > > > > @tyc > > > > > > > > > > > ho.n > > > > > > > > > > > sa > > > > > > > > > > > .gov > > > > > > > > > > > > wrote: > > > > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore > > > > > > > > > > > > wrote: > > > > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley > > > > > > > > > > > > > > > > > > > > > > > > > @tyc > > > > > > > > > > > > > ho > > > > > > > > > > > > > .nsa > > > > > > > > > > > > > .gov> > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > While I think splitting the NNP/nosuid transition > > > > > > > > > > > restrictions > > > > > > > > > > > might > > > > > > > > > > > be a good idea under the new policy capability, I'm > > > > > > > > > > > not > > > > > > > > > > > sure > > > > > > > > > > > it > > > > > > > > > > > is > > > > > > > > > > > worth the cost of a "process2" object class. > > > > > > > > > > > > > > > > > > > > > > With that in mind, let's do two things with this > > > > > > > > > > > patch: > > > > > > > > > > > > > > > > > > > > > > * Mention the nosuid restrictions in the patch > > > > > > > > > > > description. It > > > > > > > > > > > doesn't need much text, but something would be good > > > > > > > > > > > so we > > > > > > > > > > > have > > > > > > > > > > > documentation in the git log. > > > > > > > > > > > > > > > > > > > > > > * Let's pick a new permission name that is not > > > > > > > > > > > specific > > > > > > > > > > > to > > > > > > > > > > > NNP > > > > > > > > > > > or > > > > > > > > > > > nosuid. IMHO, nnpnosuid_transition is ... less than > > > > > > > > > > > good. > > > > > > > > > > > Unfortunately, I'm not sure I'm much better at > > > > > > > > > > > picking > > > > > > > > > > > names; > > > > > > > > > > > how > > > > > > > > > > > about > > > > > > > > > > > "protected_transition"? "restricted_transition"? > > > > > > > > > > > "enable_transition"? "override_transition"? > > > > > > > > > > > > &g
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Thu, Jul 13, 2017 at 02:13:40PM -0400, Stephen Smalley wrote: > On Thu, 2017-07-13 at 18:55 +0200, Dominick Grift wrote: > > On Thu, Jul 13, 2017 at 11:59:55AM -0400, Stephen Smalley wrote: > > > On Thu, 2017-07-13 at 11:48 -0400, Stephen Smalley wrote: > > > > On Thu, 2017-07-13 at 09:25 -0400, Paul Moore wrote: > > > > > On Thu, Jul 13, 2017 at 8:44 AM, Stephen Smalley <s...@tycho.nsa > > > > > .gov > > > > > > > > > > > > > > > > wrote: > > > > > > On Wed, 2017-07-12 at 20:27 -0400, Chris PeBenito wrote: > > > > > > > On 07/12/2017 05:38 PM, Paul Moore wrote: > > > > > > > > On Wed, Jul 12, 2017 at 9:26 AM, Stephen Smalley <sds@tyc > > > > > > > > ho.n > > > > > > > > sa > > > > > > > > .gov > > > > > > > > > wrote: > > > > > > > > > On Tue, 2017-07-11 at 17:00 -0400, Paul Moore wrote: > > > > > > > > > > On Mon, Jul 10, 2017 at 4:25 PM, Stephen Smalley > > > > > > > > > @tyc > > > > > > > > > > ho > > > > > > > > > > .nsa > > > > > > > > > > .gov> > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > While I think splitting the NNP/nosuid transition > > > > > > > > restrictions > > > > > > > > might > > > > > > > > be a good idea under the new policy capability, I'm not > > > > > > > > sure > > > > > > > > it > > > > > > > > is > > > > > > > > worth the cost of a "process2" object class. > > > > > > > > > > > > > > > > With that in mind, let's do two things with this patch: > > > > > > > > > > > > > > > > * Mention the nosuid restrictions in the patch > > > > > > > > description. It > > > > > > > > doesn't need much text, but something would be good so we > > > > > > > > have > > > > > > > > documentation in the git log. > > > > > > > > > > > > > > > > * Let's pick a new permission name that is not specific > > > > > > > > to > > > > > > > > NNP > > > > > > > > or > > > > > > > > nosuid. IMHO, nnpnosuid_transition is ... less than > > > > > > > > good. > > > > > > > > Unfortunately, I'm not sure I'm much better at picking > > > > > > > > names; > > > > > > > > how > > > > > > > > about "protected_transition"? "restricted_transition"? > > > > > > > > "enable_transition"? "override_transition"? > > > > > > > > > > > > > > I vote for nnp_transition anyway. "No New Privileges" > > > > > > > encompasses > > > > > > > nosuid in my mind. If the two perms had been separated I > > > > > > > would > > > > > > > have > > > > > > > been inclined to allow both every time one of them was > > > > > > > needed, > > > > > > > to > > > > > > > make > > > > > > > sure no one was surprised by the behavior difference. > > > > > > > > > > > > I agree; I'll keep it as nnp_transition and just document it > > > > > > in > > > > > > the > > > > > > patch description. > > > > > > > > > > Sorry to be a stubborn about this, but nnp_transition makes > > > > > little > > > > > sense for the nosuid restriction. Like it or not, NNP has a > > > > > concrete > > > > > meaning which is distinct from nosuid mounts. We don't have to > > > > > pick > > > > > any of the permission names I tossed out, none of those were > > > > > very > > > > > good, but I would like to see something that takes both NNP and > > > > > nosuid > > > > > into account, or preferably something that doesn't use either > > >
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
he only other alternative I see is to introduce a process2 class and > > use separate nnp_transition and nosuid_transition permissions (but in > > practice I expect them to be both allowed or denied together). Note > > that this will require two avtab and AVC entries for every domain > > pair > > (if we allow whichever one ends up going in the process2 class), so > > that has an impact on policy and AVC size. Don't really see that as > > worthwhile. > > > > Other approach would be to make the nosuid transition checks file- > > based > > instead so that it would go in the file class (while the nnp one > > would > > remain in the process class), but I don't think that's really what we > > want either. Difference between "Can domain D1 transition under > > nosuid > > to D2?" and "Can domain D1 transition under nosuid when executing > > file > > with type T1?". > > Just to be clear, we would also be separately checking regular > transition permission between the old and new contexts on these > transitions, so you would need both: > allow D1 D2:process transition; > allow D1 T1:file nosuid_transition; > if we took the latter approach. > > So we wouldn't lose entirely on a domain-to-domain check, but it would > no longer be domain-to-domain for the nosuid part. > > Whereas with original approach, we end up requiring: > allow D1 D2:process transition; > allow D1 D2:process nnp_nosuid_transition; # or whatever permission name is > used I don't know if i understand all the ins-and-outs of the matter but i think i do like the idea of differentiating between nosuid_transition and nnp_transition It provides more flexibility because i might not want to allow one or the other automatically. I do not think it its a good idea to allow a process to transiton on nosuid mounted filesystems just because i am forced to allow it nnp. So since the stuff is ugly one way or another might as well make it consistent with SELinux flexibility goals Just my preference but I dont have a really strong opinion on the matter > > > > > On a separate note, I plan to cc luto on the next version of the > > patch > > as I suspect he will have concerns about relaxing this constraint on > > NNP and this likely requires updating > > Documentation/prctl/no_new_privs* > > and the man pages that describe NNP behavior. > > > > The other model would be to figure out a way to make the typebounds > > logic work cleanly in a manner that preserves the desired NNP/nosuid > > invariant _and_ doesn't require leaking unnecessary accesses into the > > ancestor domains that make them less secure, plus CIL support for > > automatically propagating permissions in the desired way. But I > > haven't yet come up with a way to do that. We can do it in some > > cases > > by creating typebounds between the object types, e.g.: > > typebounds parent_t child_t; > > allow child_t self:process execmem; > > allow child_t child_exec_t:file entrypoint; > > allow child_t child_tmp_t:file create; > > can be allowed via: > > allow parent_t child_t:process execmem; # an otherwise nonsensical > > rule > > typebounds parent_exec_t child_exec_t; > > typebounds parent_tmp_t child_tmp_t; > > but this breaks down when there isn't an equivalent type and > > permission > > set already allowed to the parent for every type allowed to the > > child. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Wed, Jul 12, 2017 at 03:38:28PM +0200, Dominick Grift wrote: > On Wed, Jul 12, 2017 at 03:30:25PM +0200, Dominick Grift wrote: > > On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote: > > > On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote: > > > > On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley wrote: > > > > > On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote: > > > > > > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote: > > > > > > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley > > > > > > > wrote: > > > > > > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote: > > > > > > > > > As systemd ramps up enabling NoNewPrivileges (either > > > > > > > > > explicitly > > > > > > > > > in > > > > > > > > > service unit files or as a side effect of other security- > > > > > > > > > related > > > > > > > > > settings in service unit files), we're increasingly running > > > > > > > > > afoul of > > > > > > > > > its interactions with SELinux. > > > > > > > > > > > > > > > > > > The end result is bad for the security of both SELinux- > > > > > > > > > disabled > > > > > > > > > and > > > > > > > > > SELinux-enabled systems. Packagers have to turn off these > > > > > > > > > options in the unit files to preserve SELinux domain > > > > > > > > > transitions. For > > > > > > > > > users who choose to disable SELinux, this means that they > > > > > > > > > miss > > > > > > > > > out on > > > > > > > > > at least having the systemd-supported protections. For > > > > > > > > > users > > > > > > > > > who > > > > > > > > > keep > > > > > > > > > SELinux enabled, they may still be missing out on some > > > > > > > > > protections > > > > > > > > > because it isn't necessarily guaranteed that the SELinux > > > > > > > > > policy > > > > > > > > > for > > > > > > > > > that service provides the same protections in all cases. > > > > > > > > > > > > > > > > > > Our options seem to be: > > > > > > > > > > > > > > > > > > 1) Just keep on the way we are now, i.e. packagers have to > > > > > > > > > remove > > > > > > > > > default protection settings from upstream package unit > > > > > > > > > files in > > > > > > > > > order > > > > > > > > > to have them work with SELinux (and not just > > > > > > > > > NoNewPrivileges= > > > > > > > > > itself; increasingly systemd is enabling NNP as a side > > > > > > > > > effect > > > > > > > > > of > > > > > > > > > other > > > > > > > > > unit file options, even seemingly unrelated ones like > > > > > > > > > PrivateDevices). > > > > > > > > > SELinux-disabled users lose entirely, SELinux-enabled users > > > > > > > > > may > > > > > > > > > lose > > > > > > > > > (depending on whether SELinux policy provides equivalent or > > > > > > > > > better guarantees). > > > > > > > > > > > > > > > > > > 2) Change systemd to automatically disable NNP on SELinux- > > > > > > > > > enabled > > > > > > > > > systems. Unit files can be left unmodified from > > > > > > > > > upstream. SELinux- > > > > > > > > > disabled users win. SELinux-enabled users may lose. > > > > > > > > > > > > > > > > > > 3) Try to use typebounds, since we allow bounded > > > > > > > > > transitions > > > > > > > > > under > > > > > >
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Wed, Jul 12, 2017 at 03:30:25PM +0200, Dominick Grift wrote: > On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote: > > On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote: > > > On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley wrote: > > > > On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote: > > > > > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote: > > > > > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley > > > > > > wrote: > > > > > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote: > > > > > > > > As systemd ramps up enabling NoNewPrivileges (either > > > > > > > > explicitly > > > > > > > > in > > > > > > > > service unit files or as a side effect of other security- > > > > > > > > related > > > > > > > > settings in service unit files), we're increasingly running > > > > > > > > afoul of > > > > > > > > its interactions with SELinux. > > > > > > > > > > > > > > > > The end result is bad for the security of both SELinux- > > > > > > > > disabled > > > > > > > > and > > > > > > > > SELinux-enabled systems. Packagers have to turn off these > > > > > > > > options in the unit files to preserve SELinux domain > > > > > > > > transitions. For > > > > > > > > users who choose to disable SELinux, this means that they > > > > > > > > miss > > > > > > > > out on > > > > > > > > at least having the systemd-supported protections. For > > > > > > > > users > > > > > > > > who > > > > > > > > keep > > > > > > > > SELinux enabled, they may still be missing out on some > > > > > > > > protections > > > > > > > > because it isn't necessarily guaranteed that the SELinux > > > > > > > > policy > > > > > > > > for > > > > > > > > that service provides the same protections in all cases. > > > > > > > > > > > > > > > > Our options seem to be: > > > > > > > > > > > > > > > > 1) Just keep on the way we are now, i.e. packagers have to > > > > > > > > remove > > > > > > > > default protection settings from upstream package unit > > > > > > > > files in > > > > > > > > order > > > > > > > > to have them work with SELinux (and not just > > > > > > > > NoNewPrivileges= > > > > > > > > itself; increasingly systemd is enabling NNP as a side > > > > > > > > effect > > > > > > > > of > > > > > > > > other > > > > > > > > unit file options, even seemingly unrelated ones like > > > > > > > > PrivateDevices). > > > > > > > > SELinux-disabled users lose entirely, SELinux-enabled users > > > > > > > > may > > > > > > > > lose > > > > > > > > (depending on whether SELinux policy provides equivalent or > > > > > > > > better guarantees). > > > > > > > > > > > > > > > > 2) Change systemd to automatically disable NNP on SELinux- > > > > > > > > enabled > > > > > > > > systems. Unit files can be left unmodified from > > > > > > > > upstream. SELinux- > > > > > > > > disabled users win. SELinux-enabled users may lose. > > > > > > > > > > > > > > > > 3) Try to use typebounds, since we allow bounded > > > > > > > > transitions > > > > > > > > under > > > > > > > > NNP. > > > > > > > > Unit files can be left unmodified from upstream. SELinux- > > > > > > > > disabled > > > > > > > > users > > > > > > > > win. SELinux-enabled users get to benefit from systemd- > > > > > > > > provided > > > > > &g
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Wed, Jul 12, 2017 at 09:01:48AM -0400, Stephen Smalley wrote: > On Tue, 2017-07-11 at 22:44 +0200, Dominick Grift wrote: > > On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley wrote: > > > On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote: > > > > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote: > > > > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley > > > > > wrote: > > > > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote: > > > > > > > As systemd ramps up enabling NoNewPrivileges (either > > > > > > > explicitly > > > > > > > in > > > > > > > service unit files or as a side effect of other security- > > > > > > > related > > > > > > > settings in service unit files), we're increasingly running > > > > > > > afoul of > > > > > > > its interactions with SELinux. > > > > > > > > > > > > > > The end result is bad for the security of both SELinux- > > > > > > > disabled > > > > > > > and > > > > > > > SELinux-enabled systems. Packagers have to turn off these > > > > > > > options in the unit files to preserve SELinux domain > > > > > > > transitions. For > > > > > > > users who choose to disable SELinux, this means that they > > > > > > > miss > > > > > > > out on > > > > > > > at least having the systemd-supported protections. For > > > > > > > users > > > > > > > who > > > > > > > keep > > > > > > > SELinux enabled, they may still be missing out on some > > > > > > > protections > > > > > > > because it isn't necessarily guaranteed that the SELinux > > > > > > > policy > > > > > > > for > > > > > > > that service provides the same protections in all cases. > > > > > > > > > > > > > > Our options seem to be: > > > > > > > > > > > > > > 1) Just keep on the way we are now, i.e. packagers have to > > > > > > > remove > > > > > > > default protection settings from upstream package unit > > > > > > > files in > > > > > > > order > > > > > > > to have them work with SELinux (and not just > > > > > > > NoNewPrivileges= > > > > > > > itself; increasingly systemd is enabling NNP as a side > > > > > > > effect > > > > > > > of > > > > > > > other > > > > > > > unit file options, even seemingly unrelated ones like > > > > > > > PrivateDevices). > > > > > > > SELinux-disabled users lose entirely, SELinux-enabled users > > > > > > > may > > > > > > > lose > > > > > > > (depending on whether SELinux policy provides equivalent or > > > > > > > better guarantees). > > > > > > > > > > > > > > 2) Change systemd to automatically disable NNP on SELinux- > > > > > > > enabled > > > > > > > systems. Unit files can be left unmodified from > > > > > > > upstream. SELinux- > > > > > > > disabled users win. SELinux-enabled users may lose. > > > > > > > > > > > > > > 3) Try to use typebounds, since we allow bounded > > > > > > > transitions > > > > > > > under > > > > > > > NNP. > > > > > > > Unit files can be left unmodified from upstream. SELinux- > > > > > > > disabled > > > > > > > users > > > > > > > win. SELinux-enabled users get to benefit from systemd- > > > > > > > provided > > > > > > > protections. However, this option is impractical to > > > > > > > implement > > > > > > > in > > > > > > > policy > > > > > > > currently, since typebounds requires us to ensure that each > > > > > > > domain is > > > > > > > allowed everything all of its descendant domains are > > >
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Tue, Jul 11, 2017 at 04:23:29PM -0400, Stephen Smalley wrote: > On Tue, 2017-07-11 at 22:10 +0200, Dominick Grift wrote: > > On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote: > > > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley wrote: > > > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote: > > > > > As systemd ramps up enabling NoNewPrivileges (either explicitly > > > > > in > > > > > service unit files or as a side effect of other security- > > > > > related > > > > > settings in service unit files), we're increasingly running > > > > > afoul of > > > > > its interactions with SELinux. > > > > > > > > > > The end result is bad for the security of both SELinux-disabled > > > > > and > > > > > SELinux-enabled systems. Packagers have to turn off these > > > > > options in the unit files to preserve SELinux domain > > > > > transitions. For > > > > > users who choose to disable SELinux, this means that they miss > > > > > out on > > > > > at least having the systemd-supported protections. For users > > > > > who > > > > > keep > > > > > SELinux enabled, they may still be missing out on some > > > > > protections > > > > > because it isn't necessarily guaranteed that the SELinux policy > > > > > for > > > > > that service provides the same protections in all cases. > > > > > > > > > > Our options seem to be: > > > > > > > > > > 1) Just keep on the way we are now, i.e. packagers have to > > > > > remove > > > > > default protection settings from upstream package unit files in > > > > > order > > > > > to have them work with SELinux (and not just NoNewPrivileges= > > > > > itself; increasingly systemd is enabling NNP as a side effect > > > > > of > > > > > other > > > > > unit file options, even seemingly unrelated ones like > > > > > PrivateDevices). > > > > > SELinux-disabled users lose entirely, SELinux-enabled users may > > > > > lose > > > > > (depending on whether SELinux policy provides equivalent or > > > > > better guarantees). > > > > > > > > > > 2) Change systemd to automatically disable NNP on SELinux- > > > > > enabled > > > > > systems. Unit files can be left unmodified from > > > > > upstream. SELinux- > > > > > disabled users win. SELinux-enabled users may lose. > > > > > > > > > > 3) Try to use typebounds, since we allow bounded transitions > > > > > under > > > > > NNP. > > > > > Unit files can be left unmodified from upstream. SELinux- > > > > > disabled > > > > > users > > > > > win. SELinux-enabled users get to benefit from systemd- > > > > > provided > > > > > protections. However, this option is impractical to implement > > > > > in > > > > > policy > > > > > currently, since typebounds requires us to ensure that each > > > > > domain is > > > > > allowed everything all of its descendant domains are allowed, > > > > > and > > > > > this > > > > > has to be repeated for the entire chain of domain > > > > > transitions. There > > > > > is > > > > > no way to clone all allow rules from children to the parent in > > > > > policy > > > > > currently, and it is doubtful that doing so would be desirable > > > > > even > > > > > if > > > > > it were practical, as it requires leaking permissions to > > > > > objects and > > > > > operations into parent domains that could weaken their own > > > > > security > > > > > in > > > > > order to allow them to the children (e.g. if a child requires > > > > > execmem > > > > > permission, then so does the parent; if a child requires read > > > > > to a > > > > > symbolic > > > > > link or temporary file that it can write, then so does the > > > > > parent, > > > > > ...). > > > > > > > > > > 4) Decouple
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
On Tue, Jul 11, 2017 at 10:05:36PM +0200, Dominick Grift wrote: > On Tue, Jul 11, 2017 at 03:52:52PM -0400, Stephen Smalley wrote: > > On Mon, 2017-07-10 at 16:25 -0400, Stephen Smalley wrote: > > > As systemd ramps up enabling NoNewPrivileges (either explicitly in > > > service unit files or as a side effect of other security-related > > > settings in service unit files), we're increasingly running afoul of > > > its interactions with SELinux. > > > > > > The end result is bad for the security of both SELinux-disabled and > > > SELinux-enabled systems. Packagers have to turn off these > > > options in the unit files to preserve SELinux domain > > > transitions. For > > > users who choose to disable SELinux, this means that they miss out on > > > at least having the systemd-supported protections. For users who > > > keep > > > SELinux enabled, they may still be missing out on some protections > > > because it isn't necessarily guaranteed that the SELinux policy for > > > that service provides the same protections in all cases. > > > > > > Our options seem to be: > > > > > > 1) Just keep on the way we are now, i.e. packagers have to remove > > > default protection settings from upstream package unit files in order > > > to have them work with SELinux (and not just NoNewPrivileges= > > > itself; increasingly systemd is enabling NNP as a side effect of > > > other > > > unit file options, even seemingly unrelated ones like > > > PrivateDevices). > > > SELinux-disabled users lose entirely, SELinux-enabled users may lose > > > (depending on whether SELinux policy provides equivalent or > > > better guarantees). > > > > > > 2) Change systemd to automatically disable NNP on SELinux-enabled > > > systems. Unit files can be left unmodified from upstream. SELinux- > > > disabled users win. SELinux-enabled users may lose. > > > > > > 3) Try to use typebounds, since we allow bounded transitions under > > > NNP. > > > Unit files can be left unmodified from upstream. SELinux-disabled > > > users > > > win. SELinux-enabled users get to benefit from systemd-provided > > > protections. However, this option is impractical to implement in > > > policy > > > currently, since typebounds requires us to ensure that each domain is > > > allowed everything all of its descendant domains are allowed, and > > > this > > > has to be repeated for the entire chain of domain transitions. There > > > is > > > no way to clone all allow rules from children to the parent in policy > > > currently, and it is doubtful that doing so would be desirable even > > > if > > > it were practical, as it requires leaking permissions to objects and > > > operations into parent domains that could weaken their own security > > > in > > > order to allow them to the children (e.g. if a child requires execmem > > > permission, then so does the parent; if a child requires read to a > > > symbolic > > > link or temporary file that it can write, then so does the parent, > > > ...). > > > > > > 4) Decouple NNP from SELinux transitions, so that we don't have to > > > make a choice between them. Introduce a new policy capability that > > > causes the ability to transition under NNP to be based on a new > > > permission > > > check between the old and new contexts rather than > > > typebounds. Domain > > > transitions can then be allowed in policy without requiring the > > > parent > > > to be a strict superset of all of its children. The rationale for > > > this > > > divergence from NNP behavior for capabilities is that SELinux > > > permissions > > > are substantially broader than just capabilities (they express a full > > > access matrix, not just privileges) and can only be used to further > > > restrict capabilities, not grant them beyond what is already > > > permitted. > > > Unit files can be left unmodified from upstream. SELinux-disabled > > > users > > > win. SELinux-enabled users can benefit from systemd-provided > > > protections > > > and policy won't need to radically change. > > > > > > This change takes the last approach above, as it seems to be the > > > best option. > > > > > > Signed-off-by: Stephen Smalley <s...@tycho.nsa.gov> > > > --- > > >
Re: [RFC][PATCH] selinux: Introduce a policy capability and permission for NNP transitions
t; },
> > { "system",
> > { "ipc_info", "syslog_read", "syslog_mod",
> > "syslog_console", "module_request", "module_load", NULL
> > } },
> > diff --git a/security/selinux/include/security.h
> > b/security/selinux/include/security.h
> > index e91f08c..88efb1b 100644
> > --- a/security/selinux/include/security.h
> > +++ b/security/selinux/include/security.h
> > @@ -73,6 +73,7 @@ enum {
> > POLICYDB_CAPABILITY_EXTSOCKCLASS,
> > POLICYDB_CAPABILITY_ALWAYSNETWORK,
> > POLICYDB_CAPABILITY_CGROUPSECLABEL,
> > + POLICYDB_CAPABILITY_NNPTRANSITION,
> > __POLICYDB_CAPABILITY_MAX
> > };
> > #define POLICYDB_CAPABILITY_MAX (__POLICYDB_CAPABILITY_MAX - 1)
> > @@ -84,6 +85,7 @@ extern int selinux_policycap_openperm;
> > extern int selinux_policycap_extsockclass;
> > extern int selinux_policycap_alwaysnetwork;
> > extern int selinux_policycap_cgroupseclabel;
> > +extern int selinux_policycap_nnptransition;
> >
> > /*
> > * type_datum properties
> > diff --git a/security/selinux/ss/services.c
> > b/security/selinux/ss/services.c
> > index 2f02fa6..2faf47a 100644
> > --- a/security/selinux/ss/services.c
> > +++ b/security/selinux/ss/services.c
> > @@ -76,7 +76,8 @@ char
> > *selinux_policycap_names[__POLICYDB_CAPABILITY_MAX] = {
> > "open_perms",
> > "extended_socket_class",
> > "always_check_network",
> > - "cgroup_seclabel"
> > + "cgroup_seclabel",
> > + "nnp_transition"
> > };
> >
> > int selinux_policycap_netpeer;
> > @@ -84,6 +85,7 @@ int selinux_policycap_openperm;
> > int selinux_policycap_extsockclass;
> > int selinux_policycap_alwaysnetwork;
> > int selinux_policycap_cgroupseclabel;
> > +int selinux_policycap_nnptransition;
> >
> > static DEFINE_RWLOCK(policy_rwlock);
> >
> > @@ -2009,6 +2011,9 @@ static void security_load_policycaps(void)
> > selinux_policycap_cgroupseclabel =
> > ebitmap_get_bit(,
> > POLICYDB_CAPABILITY_CGROUPSECLABEL);
> > + selinux_policycap_nnptransition =
> > + ebitmap_get_bit(,
> > + POLICYDB_CAPABILITY_NNPTRANSITION);
> >
> > for (i = 0; i < ARRAY_SIZE(selinux_policycap_names); i++)
> > pr_info("SELinux: policy capability %s=%d\n",
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: run_init messes up terminal settings
On Mon, Jun 26, 2017 at 03:00:31PM -0400, Stephen Smalley wrote: > On Mon, 2017-06-26 at 14:24 -0400, Stephen Smalley wrote: > > On Mon, 2017-06-26 at 19:49 +0200, Dominick Grift wrote: > > > On Mon, Jun 26, 2017 at 01:41:05PM -0400, Stephen Smalley wrote: > > > > On Mon, 2017-06-26 at 19:20 +0200, Dominick Grift wrote: > > > > > On Mon, Jun 26, 2017 at 01:22:41PM -0400, Stephen Smalley > > > > > wrote: > > > > > > On Mon, 2017-06-26 at 18:45 +0200, Dominick Grift wrote: > > > > > > > On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley > > > > > > > wrote: > > > > > > > > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote: > > > > > > > > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen > > > > > > > > > Smalley > > > > > > > > > wrote: > > > > > > > > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville > > > > > > > > > > wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > Russell opened the following bug regarding run_init > > > > > > > > > > > in > > > > > > > > > > > the > > > > > > > > > > > debian > > > > > > > > > > > bts: > > > > > > > > > > > > > > > > > > > > > > [...] > > > > > > > > > > > It turns out that the problem was not running > > > > > > > > > > > $(arch), > > > > > > > > > > > but > > > > > > > > > > > running > > > > > > > > > > > run_init in > > > > > > > > > > > the shell it spawned. Below is an example of > > > > > > > > > > > reproducing > > > > > > > > > > > this, > > > > > > > > > > > the > > > > > > > > > > > first time > > > > > > > > > > > run_init performs as expected. The second time is > > > > > > > > > > > fails > > > > > > > > > > > without > > > > > > > > > > > me > > > > > > > > > > > even > > > > > > > > > > > typing a password or pressing ENTER. The result is > > > > > > > > > > > the > > > > > > > > > > > same > > > > > > > > > > > with > > > > > > > > > > > any > > > > > > > > > > > command, > > > > > > > > > > > but ls is just a good example. This happens no > > > > > > > > > > > matter > > > > > > > > > > > what > > > > > > > > > > > shell > > > > > > > > > > > is > > > > > > > > > > > spawned > > > > > > > > > > > (whether it's ssh, su, or just an Xterm), run_init > > > > > > > > > > > seems > > > > > > > > > > > generally > > > > > > > > > > > broken with > > > > > > > > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least. > > > > > > > > > > > > > > > > > > > > > > NB I can't rule out the possibility of a kernel bug > > > > > > > > > > > at > > > > > > > > > > > this > > > > > > > > > > > stage. But at > > > > > > > > > > > this time it seems best to assume it's a run_init > > > > > > > > > > > bug > > > > > > > > > > > until > > > > > > > > > > > proven > > > > > > > > > > > otherwise. > > > > > > > > > > > > > > > > > > > > > > Sorry for the inconvenience Andreas. > > > > > > > > > > > > > > > > > > > > > > # run_init ls
Re: run_init messes up terminal settings
On Mon, Jun 26, 2017 at 01:41:05PM -0400, Stephen Smalley wrote: > On Mon, 2017-06-26 at 19:20 +0200, Dominick Grift wrote: > > On Mon, Jun 26, 2017 at 01:22:41PM -0400, Stephen Smalley wrote: > > > On Mon, 2017-06-26 at 18:45 +0200, Dominick Grift wrote: > > > > On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley wrote: > > > > > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote: > > > > > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley > > > > > > wrote: > > > > > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville > > > > > > > wrote: > > > > > > > > Hello, > > > > > > > > Russell opened the following bug regarding run_init in > > > > > > > > the > > > > > > > > debian > > > > > > > > bts: > > > > > > > > > > > > > > > > [...] > > > > > > > > It turns out that the problem was not running $(arch), > > > > > > > > but > > > > > > > > running > > > > > > > > run_init in > > > > > > > > the shell it spawned. Below is an example of reproducing > > > > > > > > this, > > > > > > > > the > > > > > > > > first time > > > > > > > > run_init performs as expected. The second time is fails > > > > > > > > without > > > > > > > > me > > > > > > > > even > > > > > > > > typing a password or pressing ENTER. The result is the > > > > > > > > same > > > > > > > > with > > > > > > > > any > > > > > > > > command, > > > > > > > > but ls is just a good example. This happens no matter > > > > > > > > what > > > > > > > > shell > > > > > > > > is > > > > > > > > spawned > > > > > > > > (whether it's ssh, su, or just an Xterm), run_init seems > > > > > > > > generally > > > > > > > > broken with > > > > > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least. > > > > > > > > > > > > > > > > NB I can't rule out the possibility of a kernel bug at > > > > > > > > this > > > > > > > > stage. But at > > > > > > > > this time it seems best to assume it's a run_init bug > > > > > > > > until > > > > > > > > proven > > > > > > > > otherwise. > > > > > > > > > > > > > > > > Sorry for the inconvenience Andreas. > > > > > > > > > > > > > > > > # run_init ls /boot > > > > > > > > Authenticating root. > > > > > > > > Password: > > > > > > > > config-4.9.0-2- > > > > > > > > amd64 lost+foundSystem.map- > > > > > > > > 4.9.0- > > > > > > > > 3-amd64 > > > > > > > > config-4.9.0-3- > > > > > > > > amd64 memtest86+.binvmlinuz- > > > > > > > > 4.9.0-2- > > > > > > > > amd64 > > > > > > > > grub memtest86+_multiboot.bin vmlin > > > > > > > > uz- > > > > > > > > 4.9.0-3- > > > > > > > > amd64 > > > > > > > > initrd.img-4.9.0-2-amd64 real > > > > > > > > initrd.img-4.9.0-3-amd64 System.map-4.9.0-2-amd64 > > > > > > > > # run_init ls /boot > > > > > > > > Authenticating root. > > > > > > > > Password: > > > > > > > > run_init: incorrect password for root > > > > > > > > authentication failed. > > > > > > > > # > > > > > > > > > > > > > > > > I can reproduce this with 2.7-rc3, run_init is compiled > > > > > > > > with > > > > > > > > pam > > > > > > > > and > > > > > > > > audit suppo
Re: run_init messes up terminal settings
On Mon, Jun 26, 2017 at 01:22:41PM -0400, Stephen Smalley wrote: > On Mon, 2017-06-26 at 18:45 +0200, Dominick Grift wrote: > > On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley wrote: > > > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote: > > > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley wrote: > > > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote: > > > > > > Hello, > > > > > > Russell opened the following bug regarding run_init in the > > > > > > debian > > > > > > bts: > > > > > > > > > > > > [...] > > > > > > It turns out that the problem was not running $(arch), but > > > > > > running > > > > > > run_init in > > > > > > the shell it spawned. Below is an example of reproducing > > > > > > this, > > > > > > the > > > > > > first time > > > > > > run_init performs as expected. The second time is fails > > > > > > without > > > > > > me > > > > > > even > > > > > > typing a password or pressing ENTER. The result is the same > > > > > > with > > > > > > any > > > > > > command, > > > > > > but ls is just a good example. This happens no matter what > > > > > > shell > > > > > > is > > > > > > spawned > > > > > > (whether it's ssh, su, or just an Xterm), run_init seems > > > > > > generally > > > > > > broken with > > > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least. > > > > > > > > > > > > NB I can't rule out the possibility of a kernel bug at this > > > > > > stage. But at > > > > > > this time it seems best to assume it's a run_init bug until > > > > > > proven > > > > > > otherwise. > > > > > > > > > > > > Sorry for the inconvenience Andreas. > > > > > > > > > > > > # run_init ls /boot > > > > > > Authenticating root. > > > > > > Password: > > > > > > config-4.9.0-2- > > > > > > amd64 lost+foundSystem.map- > > > > > > 4.9.0- > > > > > > 3-amd64 > > > > > > config-4.9.0-3-amd64 memtest86+.binvmlinuz- > > > > > > 4.9.0-2- > > > > > > amd64 > > > > > > grub memtest86+_multiboot.bin vmlinuz- > > > > > > 4.9.0-3- > > > > > > amd64 > > > > > > initrd.img-4.9.0-2-amd64 real > > > > > > initrd.img-4.9.0-3-amd64 System.map-4.9.0-2-amd64 > > > > > > # run_init ls /boot > > > > > > Authenticating root. > > > > > > Password: > > > > > > run_init: incorrect password for root > > > > > > authentication failed. > > > > > > # > > > > > > > > > > > > I can reproduce this with 2.7-rc3, run_init is compiled with > > > > > > pam > > > > > > and > > > > > > audit support. > > > > > > An idea what could happen here? > > > > > > Regards, > > > > > > Laurent Bigonville > > > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187 > > > > > > > > > > I don't think this could have ever worked under run_init since > > > > > open_init_pty was introduced (originally from Debian); note > > > > > that > > > > > open_init_pty does alter terminal settings. > > > > > > > > > > I don't quite follow the example given above. It shows > > > > > executing > > > > > run_init twice with ls /boot as the arguments, which is not > > > > > running > > > > > run_init within run_init. That works fine for me. > > > > > > > > > > If I try something like: > > > > > run_init run_init ls /boot > > > > > which actually runs run_init within run_init, then that also > > > > > works > > > > > for > > > > > me without problem. > > > > > > > > > > If I try something l
Re: run_init messes up terminal settings
On Mon, Jun 26, 2017 at 11:50:10AM -0400, Stephen Smalley wrote: > On Mon, 2017-06-26 at 15:26 +0200, Dominick Grift wrote: > > On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley wrote: > > > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote: > > > > Hello, > > > > Russell opened the following bug regarding run_init in the debian > > > > bts: > > > > > > > > [...] > > > > It turns out that the problem was not running $(arch), but > > > > running > > > > run_init in > > > > the shell it spawned. Below is an example of reproducing this, > > > > the > > > > first time > > > > run_init performs as expected. The second time is fails without > > > > me > > > > even > > > > typing a password or pressing ENTER. The result is the same with > > > > any > > > > command, > > > > but ls is just a good example. This happens no matter what shell > > > > is > > > > spawned > > > > (whether it's ssh, su, or just an Xterm), run_init seems > > > > generally > > > > broken with > > > > the 4.9.0-2-amd64/4.9.13-1 kernel at least. > > > > > > > > NB I can't rule out the possibility of a kernel bug at this > > > > stage. But at > > > > this time it seems best to assume it's a run_init bug until > > > > proven > > > > otherwise. > > > > > > > > Sorry for the inconvenience Andreas. > > > > > > > > # run_init ls /boot > > > > Authenticating root. > > > > Password: > > > > config-4.9.0-2-amd64 lost+foundSystem.map- > > > > 4.9.0- > > > > 3-amd64 > > > > config-4.9.0-3-amd64 memtest86+.binvmlinuz- > > > > 4.9.0-2- > > > > amd64 > > > > grub memtest86+_multiboot.bin vmlinuz- > > > > 4.9.0-3- > > > > amd64 > > > > initrd.img-4.9.0-2-amd64 real > > > > initrd.img-4.9.0-3-amd64 System.map-4.9.0-2-amd64 > > > > # run_init ls /boot > > > > Authenticating root. > > > > Password: > > > > run_init: incorrect password for root > > > > authentication failed. > > > > # > > > > > > > > I can reproduce this with 2.7-rc3, run_init is compiled with pam > > > > and > > > > audit support. > > > > An idea what could happen here? > > > > Regards, > > > > Laurent Bigonville > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187 > > > > > > I don't think this could have ever worked under run_init since > > > open_init_pty was introduced (originally from Debian); note that > > > open_init_pty does alter terminal settings. > > > > > > I don't quite follow the example given above. It shows executing > > > run_init twice with ls /boot as the arguments, which is not running > > > run_init within run_init. That works fine for me. > > > > > > If I try something like: > > > run_init run_init ls /boot > > > which actually runs run_init within run_init, then that also works > > > for > > > me without problem. > > > > > > If I try something like: > > > run_init /bin/bash > > > then I lose any echoing of input characters to the shell (due to > > > open_init_pty turning it off), but I can enter commands and execute > > > them, or run stty sane to regain echoing. But I don't think that > > > has > > > ever been supported since the introduction of open_init_pty in 2005 > > > (policycoreutils 1.21.2). What's the use case for it? > > > > > > Side bar: run_init (and open_init_pty) are no longer packaged by > > > Fedora > > > since systemd renders it unnecessary, and even prior to that, > > > Fedora > > > policy enabled DIRECT_INITRC=y in build.conf, and therefore > > > run_init > > > > Correct me if i am wrong but fedora has DIRECT_INITRC=n AFAICT > > > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selin > > ux-policy.spec#n173 > > https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selin > > ux-policy.spec#n393 > > > > I vaguely recall that in a strict environment one still might need > > run_init for the `update aliases` functionality in redhar-bas
Re: run_init messes up terminal settings
On Mon, Jun 26, 2017 at 09:08:16AM -0400, Stephen Smalley wrote: > On Sat, 2017-06-24 at 12:20 +0200, Laurent Bigonville wrote: > > Hello, > > Russell opened the following bug regarding run_init in the debian > > bts: > > > > [...] > > It turns out that the problem was not running $(arch), but running > > run_init in > > the shell it spawned. Below is an example of reproducing this, the > > first time > > run_init performs as expected. The second time is fails without me > > even > > typing a password or pressing ENTER. The result is the same with any > > command, > > but ls is just a good example. This happens no matter what shell is > > spawned > > (whether it's ssh, su, or just an Xterm), run_init seems generally > > broken with > > the 4.9.0-2-amd64/4.9.13-1 kernel at least. > > > > NB I can't rule out the possibility of a kernel bug at this > > stage. But at > > this time it seems best to assume it's a run_init bug until proven > > otherwise. > > > > Sorry for the inconvenience Andreas. > > > > # run_init ls /boot > > Authenticating root. > > Password: > > config-4.9.0-2-amd64 lost+foundSystem.map-4.9.0- > > 3-amd64 > > config-4.9.0-3-amd64 memtest86+.binvmlinuz-4.9.0-2- > > amd64 > > grub memtest86+_multiboot.bin vmlinuz-4.9.0-3- > > amd64 > > initrd.img-4.9.0-2-amd64 real > > initrd.img-4.9.0-3-amd64 System.map-4.9.0-2-amd64 > > # run_init ls /boot > > Authenticating root. > > Password: > > run_init: incorrect password for root > > authentication failed. > > # > > > > I can reproduce this with 2.7-rc3, run_init is compiled with pam and > > audit support. > > An idea what could happen here? > > Regards, > > Laurent Bigonville > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863187 > > I don't think this could have ever worked under run_init since > open_init_pty was introduced (originally from Debian); note that > open_init_pty does alter terminal settings. > > I don't quite follow the example given above. It shows executing > run_init twice with ls /boot as the arguments, which is not running > run_init within run_init. That works fine for me. > > If I try something like: > run_init run_init ls /boot > which actually runs run_init within run_init, then that also works for > me without problem. > > If I try something like: > run_init /bin/bash > then I lose any echoing of input characters to the shell (due to > open_init_pty turning it off), but I can enter commands and execute > them, or run stty sane to regain echoing. But I don't think that has > ever been supported since the introduction of open_init_pty in 2005 > (policycoreutils 1.21.2). What's the use case for it? > > Side bar: run_init (and open_init_pty) are no longer packaged by Fedora > since systemd renders it unnecessary, and even prior to that, Fedora > policy enabled DIRECT_INITRC=y in build.conf, and therefore run_init Correct me if i am wrong but fedora has DIRECT_INITRC=n AFAICT https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selinux-policy.spec#n173 https://src.fedoraproject.org/cgit/rpms/selinux-policy.git/tree/selinux-policy.spec#n393 I vaguely recall that in a strict environment one still might need run_init for the `update aliases` functionality in redhar-based distributions.. i might be wrong though > wasn't required for typical operation (maybe under -mls policy it was > still needed, not sure). Possibly we should move run_init out of > policycoreutils into its own subdirectory in the selinux userspace tree > to reflect this transition and start deprecating it. > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: Collecting ideas for audit2allow improvement
On Mon, Jun 19, 2017 at 11:45:53AM -0400, Daniel Walsh wrote: > On 06/16/2017 12:08 PM, Dominick Grift wrote: > > On Fri, Jun 16, 2017 at 08:21:25AM -0400, Daniel Walsh wrote: > > > On 06/14/2017 10:47 AM, Dominick Grift wrote: > > > > On Wed, Jun 14, 2017 at 04:35:41PM +0200, Dominick Grift wrote: > > > > > On Wed, Jun 14, 2017 at 10:30:25AM -0400, Stephen Smalley wrote: > > > > > > On Wed, 2017-06-14 at 09:01 -0400, Jan Zarsky wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I would like to improve SELinux audit2allow tool as my bachelor > > > > > > > thesis. > > > > > > > I collected ideas from my colleagues from RedHat SELinux team and > > > > > > > I > > > > > > > would also > > > > > > > like to hear your ideas - what would you improve to make > > > > > > > audit2allow > > > > > > > smarter or > > > > > > > easier to use. > > > > > > > > > > > > > > Ideas collected so far: > > > > > > > > > > > > > > * offer dac_read_search when sufficient instead of > > > > > > > dac_override > > > > > > > (see <https://github.com/SELinuxProject/selinux/issues/31>) > > > > > > The hard part here is knowing when it is sufficient. Might require > > > > > > further kernel patches to get to the point where it is completely > > > > > > unambiguous from the audit messages alone. You could perhaps > > > > > > default > > > > > > to only allowing dac_read_search and only allow dac_override if you > > > > > > see > > > > > > that dac_read_search is already allowed and you are still getting a > > > > > > dac_override denial. > > > > > This should not be an issue anymore. Becuase now (linux v4.12) > > > > > dac_read_search is first checked > > > > > so translating a rule for dac_read_search will always be the most > > > > > secure option. It might not be enough but youll notice if it isnt. > > > > > Just rerun it again and you'll end up with dac_override if needed. > > > > > > > > > > > > * offer multiple solutions to a problem (example: 1) add > > > > > > > allow rule > > > > > > > for > > > > > > > execute + execute_no_trans or 2) add allow rule for execute > > > > > > > + type_transition rule) > > > > > > Is this type_transition to an existing type that already exists, or > > > > > > defining a new type and transitioning to it, or both? Generating > > > > > > new > > > > > > domains and types dynamically is one of the major gaps in current > > > > > > audit2allow, and to date has only been supported in separate tools > > > > > > like > > > > > > sepolicy generate. > > > > > One should be extremely careful here. "execute" does not > > > > > automatically imply "execute_no_trans". That assumption can lead to > > > > > disaster (https://www.cvedetails.com/cve/CVE-2015-1815/) > > > > > > > * interactive mode: ask questions and choose best solution > > > > > > > * warn when solution touches trusted computing base (rules you > > > > > > > should not be > > > > > > > adding) > > > > > > > * suggest alternate labels for content, example: httpd_t not > > > > > > > allowed to write > > > > > > > to user_home_t, might suggest that changing the label to > > > > > > > httpd_user_content_t > > > > > > This seems more along the lines of what setroubleshoot does, and > > > > > > tends > > > > > > to be policy-specific. We need to preserve the usability of > > > > > > audit2allow > > > > > > for other policies (e.g. Android, DSSP), so any policy-specific > > > > > > logic > > > > > > needs to be encapsulated, configuration-driven, and optional. > > > > > setroubleshoot is not smart enough to suggest httpd_user_content_t, > > > > > instead it suggest you allow full access to /home/* by toggling
Re: Collecting ideas for audit2allow improvement
On Fri, Jun 16, 2017 at 08:21:25AM -0400, Daniel Walsh wrote: > On 06/14/2017 10:47 AM, Dominick Grift wrote: > > On Wed, Jun 14, 2017 at 04:35:41PM +0200, Dominick Grift wrote: > > > On Wed, Jun 14, 2017 at 10:30:25AM -0400, Stephen Smalley wrote: > > > > On Wed, 2017-06-14 at 09:01 -0400, Jan Zarsky wrote: > > > > > Hi, > > > > > > > > > > I would like to improve SELinux audit2allow tool as my bachelor > > > > > thesis. > > > > > I collected ideas from my colleagues from RedHat SELinux team and I > > > > > would also > > > > > like to hear your ideas - what would you improve to make audit2allow > > > > > smarter or > > > > > easier to use. > > > > > > > > > > Ideas collected so far: > > > > > > > > > >* offer dac_read_search when sufficient instead of dac_override > > > > > (see <https://github.com/SELinuxProject/selinux/issues/31>) > > > > The hard part here is knowing when it is sufficient. Might require > > > > further kernel patches to get to the point where it is completely > > > > unambiguous from the audit messages alone. You could perhaps default > > > > to only allowing dac_read_search and only allow dac_override if you see > > > > that dac_read_search is already allowed and you are still getting a > > > > dac_override denial. > > > This should not be an issue anymore. Becuase now (linux v4.12) > > > dac_read_search is first checked > > > so translating a rule for dac_read_search will always be the most secure > > > option. It might not be enough but youll notice if it isnt. Just rerun it > > > again and you'll end up with dac_override if needed. > > > > > > > >* offer multiple solutions to a problem (example: 1) add allow rule > > > > > for > > > > > execute + execute_no_trans or 2) add allow rule for execute > > > > > + type_transition rule) > > > > Is this type_transition to an existing type that already exists, or > > > > defining a new type and transitioning to it, or both? Generating new > > > > domains and types dynamically is one of the major gaps in current > > > > audit2allow, and to date has only been supported in separate tools like > > > > sepolicy generate. > > > One should be extremely careful here. "execute" does not automatically > > > imply "execute_no_trans". That assumption can lead to disaster > > > (https://www.cvedetails.com/cve/CVE-2015-1815/) > > > > >* interactive mode: ask questions and choose best solution > > > > >* warn when solution touches trusted computing base (rules you > > > > > should not be > > > > > adding) > > > > >* suggest alternate labels for content, example: httpd_t not > > > > > allowed to write > > > > > to user_home_t, might suggest that changing the label to > > > > > httpd_user_content_t > > > > This seems more along the lines of what setroubleshoot does, and tends > > > > to be policy-specific. We need to preserve the usability of audit2allow > > > > for other policies (e.g. Android, DSSP), so any policy-specific logic > > > > needs to be encapsulated, configuration-driven, and optional. > > > setroubleshoot is not smart enough to suggest httpd_user_content_t, > > > instead it suggest you allow full access to /home/* by toggling the > > > boolean that grants access to user home content. > > > > > > I know this from experience. There was a bug in fedora's > > > apache_user_content_template for more than a year and hardly anyone > > > noticed it, probably because setroubleshoot would have just suggested you > > > allow full access to user home content. > > https://bugzilla.redhat.com/show_bug.cgi?id=1457406 > I actually think the suggest a accessible type is the best improvement. > audit2allow has defaulted for years to suggesting adding allow rules, > usually the worst solution. Later we added boolean support, which was > better but as you point out the not a great solution in a lot of cases. The "best" improvement. I agree, but that say's more about the overal state of things than about the quality of this particular improvement. The guy in the tweet was overwhelmed and intimidated by the large list of "accessible" types returned by setroubleshoot (and audit2allow wou
Re: [PATCH] libsepol/cil: Fix bugs when writing policy.conf rules
On Wed, Jun 14, 2017 at 01:39:07PM -0400, James Carter wrote:
> The typebounds rules should end with a ";".
>
> The netifcon and nodecon rules should not end with a ";".
>
> The default rules are missing a "_". They should be "default_usr",
> "default_role" and "default_type".
I might be misunderstanding but according to
https://selinuxproject.org/page/DefaultRules#default_user it should be
"default_user"
>
> Signed-off-by: James Carter <jwca...@tycho.nsa.gov>
> ---
> libsepol/cil/src/cil_policy.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libsepol/cil/src/cil_policy.c b/libsepol/cil/src/cil_policy.c
> index 2196ae8..f7fe24e 100644
> --- a/libsepol/cil/src/cil_policy.c
> +++ b/libsepol/cil/src/cil_policy.c
> @@ -1069,7 +1069,7 @@ static void cil_typebounds_to_policy(FILE *out, struct
> cil_list *types)
> child = i1->data;
> if (child->bounds != NULL) {
> parent = child->bounds;
> - fprintf(out, "typebounds %s %s\n", parent->datum.fqn,
> child->datum.fqn);
> + fprintf(out, "typebounds %s %s;\n", parent->datum.fqn,
> child->datum.fqn);
> }
> }
> }
> @@ -1779,7 +1779,7 @@ static void cil_netifcons_to_policy(FILE *out, struct
> cil_sort *netifcons, int m
> cil_context_to_policy(out, netifcon->if_context, mls);
> fprintf(out, " ");
> cil_context_to_policy(out, netifcon->packet_context, mls);
> - fprintf(out, ";\n");
> + fprintf(out, "\n");
> }
> }
>
> @@ -1836,7 +1836,7 @@ static void cil_nodecons_to_policy(FILE *out, struct
> cil_sort *nodecons, int mls
> }
>
> cil_context_to_policy(out, nodecon->context, mls);
> - fprintf(out, ";\n");
> + fprintf(out, "\n");
> }
> }
>
> @@ -1928,9 +1928,9 @@ void cil_gen_policy(FILE *out, struct cil_db *db)
> cil_commons_to_policy(out, lists[CIL_LIST_COMMON]);
> cil_classes_to_policy(out, db->classorder);
>
> - cil_defaults_to_policy(out, lists[CIL_LIST_DEFAULT_USER],
> CIL_KEY_DEFAULTUSER);
> - cil_defaults_to_policy(out, lists[CIL_LIST_DEFAULT_ROLE],
> CIL_KEY_DEFAULTROLE);
> - cil_defaults_to_policy(out, lists[CIL_LIST_DEFAULT_TYPE],
> CIL_KEY_DEFAULTTYPE);
> + cil_defaults_to_policy(out, lists[CIL_LIST_DEFAULT_USER],
> "default_usr");
> + cil_defaults_to_policy(out, lists[CIL_LIST_DEFAULT_ROLE],
> "default_role");
> + cil_defaults_to_policy(out, lists[CIL_LIST_DEFAULT_TYPE],
> "default_type");
>
> if (db->mls == CIL_TRUE) {
> cil_default_ranges_to_policy(out,
> lists[CIL_LIST_DEFAULT_RANGE]);
> --
> 2.9.4
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: Collecting ideas for audit2allow improvement
On Wed, Jun 14, 2017 at 04:35:41PM +0200, Dominick Grift wrote: > On Wed, Jun 14, 2017 at 10:30:25AM -0400, Stephen Smalley wrote: > > On Wed, 2017-06-14 at 09:01 -0400, Jan Zarsky wrote: > > > Hi, > > > > > > I would like to improve SELinux audit2allow tool as my bachelor > > > thesis. > > > I collected ideas from my colleagues from RedHat SELinux team and I > > > would also > > > like to hear your ideas - what would you improve to make audit2allow > > > smarter or > > > easier to use. > > > > > > Ideas collected so far: > > > > > > * offer dac_read_search when sufficient instead of dac_override > > > (see <https://github.com/SELinuxProject/selinux/issues/31>) > > > > The hard part here is knowing when it is sufficient. Might require > > further kernel patches to get to the point where it is completely > > unambiguous from the audit messages alone. You could perhaps default > > to only allowing dac_read_search and only allow dac_override if you see > > that dac_read_search is already allowed and you are still getting a > > dac_override denial. > > This should not be an issue anymore. Becuase now (linux v4.12) > dac_read_search is first checked > so translating a rule for dac_read_search will always be the most secure > option. It might not be enough but youll notice if it isnt. Just rerun it > again and you'll end up with dac_override if needed. > > > > > > * offer multiple solutions to a problem (example: 1) add allow rule > > > for > > > execute + execute_no_trans or 2) add allow rule for execute > > > + type_transition rule) > > > > Is this type_transition to an existing type that already exists, or > > defining a new type and transitioning to it, or both? Generating new > > domains and types dynamically is one of the major gaps in current > > audit2allow, and to date has only been supported in separate tools like > > sepolicy generate. > > One should be extremely careful here. "execute" does not automatically imply > "execute_no_trans". That assumption can lead to disaster > (https://www.cvedetails.com/cve/CVE-2015-1815/) > > > > > * interactive mode: ask questions and choose best solution > > > * warn when solution touches trusted computing base (rules you > > > should not be > > > adding) > > > * suggest alternate labels for content, example: httpd_t not > > > allowed to write > > > to user_home_t, might suggest that changing the label to > > > httpd_user_content_t > > > > This seems more along the lines of what setroubleshoot does, and tends > > to be policy-specific. We need to preserve the usability of audit2allow > > for other policies (e.g. Android, DSSP), so any policy-specific logic > > needs to be encapsulated, configuration-driven, and optional. > > setroubleshoot is not smart enough to suggest httpd_user_content_t, instead > it suggest you allow full access to /home/* by toggling the boolean that > grants access to user home content. > > I know this from experience. There was a bug in fedora's > apache_user_content_template for more than a year and hardly anyone noticed > it, probably because setroubleshoot would have just suggested you allow full > access to user home content. https://bugzilla.redhat.com/show_bug.cgi?id=1457406 > > > > > > * output to CIL (add option for this) > > > > This would definitely be useful, as generating .te files just adds > > overhead at this point and makes audit2allow depend on having > > checkmodule and semodule_package installed. In fact, I think we should > > move to generating CIL by default and just provide an option for > > generating .te files for backward compat. > > > > > * if the AVC talks about execute permission then offer also > > > type_transition > > > rule > > > * idea for a tool for automatic policy generation: On a test system > > > you > > > install application, turn the SELinux to permissive and run a > > > full test > > > suit. You collect all the AVCs in say Elasticsearch (can use > > > common logging > > > ViaQ project for that) and then there is a tool that searches the > > > AVC, > > > groups them and creates a policy out of them. > > > > This seems similar to sepolicy generate. We don't want to bring in > > many extra dependencies to audit2allow, but being able to dynamically > > generate new domains and
Re: Collecting ideas for audit2allow improvement
On Wed, Jun 14, 2017 at 10:30:25AM -0400, Stephen Smalley wrote:
> On Wed, 2017-06-14 at 09:01 -0400, Jan Zarsky wrote:
> > Hi,
> >
> > I would like to improve SELinux audit2allow tool as my bachelor
> > thesis.
> > I collected ideas from my colleagues from RedHat SELinux team and I
> > would also
> > like to hear your ideas - what would you improve to make audit2allow
> > smarter or
> > easier to use.
> >
> > Ideas collected so far:
> >
> > * offer dac_read_search when sufficient instead of dac_override
> > (see <https://github.com/SELinuxProject/selinux/issues/31>)
>
> The hard part here is knowing when it is sufficient. Might require
> further kernel patches to get to the point where it is completely
> unambiguous from the audit messages alone. You could perhaps default
> to only allowing dac_read_search and only allow dac_override if you see
> that dac_read_search is already allowed and you are still getting a
> dac_override denial.
This should not be an issue anymore. Becuase now (linux v4.12) dac_read_search
is first checked
so translating a rule for dac_read_search will always be the most secure
option. It might not be enough but youll notice if it isnt. Just rerun it again
and you'll end up with dac_override if needed.
>
> > * offer multiple solutions to a problem (example: 1) add allow rule
> > for
> > execute + execute_no_trans or 2) add allow rule for execute
> > + type_transition rule)
>
> Is this type_transition to an existing type that already exists, or
> defining a new type and transitioning to it, or both? Generating new
> domains and types dynamically is one of the major gaps in current
> audit2allow, and to date has only been supported in separate tools like
> sepolicy generate.
One should be extremely careful here. "execute" does not automatically imply
"execute_no_trans". That assumption can lead to disaster
(https://www.cvedetails.com/cve/CVE-2015-1815/)
>
> > * interactive mode: ask questions and choose best solution
> > * warn when solution touches trusted computing base (rules you
> > should not be
> > adding)
> > * suggest alternate labels for content, example: httpd_t not
> > allowed to write
> > to user_home_t, might suggest that changing the label to
> > httpd_user_content_t
>
> This seems more along the lines of what setroubleshoot does, and tends
> to be policy-specific. We need to preserve the usability of audit2allow
> for other policies (e.g. Android, DSSP), so any policy-specific logic
> needs to be encapsulated, configuration-driven, and optional.
setroubleshoot is not smart enough to suggest httpd_user_content_t, instead it
suggest you allow full access to /home/* by toggling the boolean that grants
access to user home content.
I know this from experience. There was a bug in fedora's
apache_user_content_template for more than a year and hardly anyone noticed it,
probably because setroubleshoot would have just suggested you allow full access
to user home content.
>
> > * output to CIL (add option for this)
>
> This would definitely be useful, as generating .te files just adds
> overhead at this point and makes audit2allow depend on having
> checkmodule and semodule_package installed. In fact, I think we should
> move to generating CIL by default and just provide an option for
> generating .te files for backward compat.
>
> > * if the AVC talks about execute permission then offer also
> > type_transition
> > rule
> > * idea for a tool for automatic policy generation: On a test system
> > you
> > install application, turn the SELinux to permissive and run a
> > full test
> > suit. You collect all the AVCs in say Elasticsearch (can use
> > common logging
> > ViaQ project for that) and then there is a tool that searches the
> > AVC,
> > groups them and creates a policy out of them.
>
> This seems similar to sepolicy generate. We don't want to bring in
> many extra dependencies to audit2allow, but being able to dynamically
> generate new domains and types would IMHO be useful.
>
> > * add option to open bugzilla
>
> Need to be careful here since not all SELinux users are Red Hat users.
>
> > * output to Ansible playbook/role task (add option for this)
>
> Another improvement:
>
> * Add ability to generate ioctl whitelisting rules, see for example:
> http://jeffvanderstoep.blogspot.com/2016/02/collecting-ioctl-command-denials-for.html
> but note that the syntax has changed to e.g.
> allowxperm : ioctl { command values> };
>
> > I would also like to know which feature would you appreciate the
> > most.
>
> You should likely study the tooling and workflow used by other security
> projects, e.g. AppArmor, TOMOYO, grsecurity, for policy learning and
> generation.
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: Collecting ideas for audit2allow improvement
On Wed, Jun 14, 2017 at 09:58:43AM -0400, jwcart2 wrote: > On 06/14/2017 09:01 AM, Jan Zarsky wrote: > > Hi, > > > > I would like to improve SELinux audit2allow tool as my bachelor thesis. > > I collected ideas from my colleagues from RedHat SELinux team and I would > > also > > like to hear your ideas - what would you improve to make audit2allow > > smarter or > > easier to use. > > > > Ideas collected so far: > > > >* offer dac_read_search when sufficient instead of dac_override > > (see <https://github.com/SELinuxProject/selinux/issues/31>) > >* offer multiple solutions to a problem (example: 1) add allow rule for > > execute + execute_no_trans or 2) add allow rule for execute > > + type_transition rule) > >* interactive mode: ask questions and choose best solution > >* warn when solution touches trusted computing base (rules you should > > not be > > adding) > >* suggest alternate labels for content, example: httpd_t not allowed to > > write > > to user_home_t, might suggest that changing the label to > > httpd_user_content_t > >* output to CIL (add option for this) > > This would definitely be helpful and should be relatively straightforward. > > Jim I will second that. I actually think this is the only compelling improvement in the whole list. Except this (which isnt in the list): https://twitter.com/evilSnobu/status/871787143781285889 Granted, its about sealert but it applies to audit2allow as well. Do not overwhelm users: they will get intimidated. The idea is that things should improve security not to just dump a long list of (mostly terrible) options on unsuspecting users Focus on making audit2allow more enjoyable to use. Waste no time on impossible missions, remove all the functionality that tries to do the impossible and does it terribly. Stick with the basics, its a helper tool, its not some magic tool that can make security decisions on your behalf, and it never will be > > >* if the AVC talks about execute permission then offer also > > type_transition > > rule > >* idea for a tool for automatic policy generation: On a test system you > > install application, turn the SELinux to permissive and run a full test > > suit. You collect all the AVCs in say Elasticsearch (can use common > > logging > > ViaQ project for that) and then there is a tool that searches the AVC, > > groups them and creates a policy out of them. > >* add option to open bugzilla > >* output to Ansible playbook/role task (add option for this) > > > > I would also like to know which feature would you appreciate the most. > > > > Thanks > > > > Jan Zarsky > > > > > -- > James Carter <jwca...@tycho.nsa.gov> > National Security Agency -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
icmp and rawip socket
Was it intentional to add icmp_socket class? Because this use to be rawip_socket. rawip_socket includes more than just icmp (IGMP/OSPF) but still I thought that the extended socket classes only applied to what is otherwise generic "socket" -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: [PATCH] libsepol/cil: better error message with duplicate aliases + support aliases to aliases
On Fri, Jun 02, 2017 at 07:12:25AM -0400, Steve Lawrence wrote: > On 06/02/2017 05:18 AM, Dominick Grift wrote: > > On Thu, Jun 01, 2017 at 11:37:11PM +0200, Nicolas Iooss wrote: > >> On Thu, Jun 1, 2017 at 7:05 PM, jwcart2 <jwca...@tycho.nsa.gov> wrote: > >>> On 06/01/2017 09:23 AM, Steve Lawrence wrote: > >>>> > >>>> - If two typealiasactual statements exist for the same typealias, we get > >>>>a confusing error message mentioning that the actual arguement is not > >>>>an alias, which is clearly allowed. This poor error occurs because the > >>>>first typealiasactual statement resolves correctly, but when we > >>>>resolve the alias in the second typealiasactual statement, > >>>>cil_resolve_name tries to return what the alias points to, which is a > >>>>type and not the required typealias. This patch creates a new function > >>>>that does not perform the alias to actual conversion, used when we > >>>>want an alias and not what the alias points to. This allows the > >>>>cil_resolve_aliasactual to continue and reach the check for duplicate > >>>>typealiasactual statements, resulting in a more meaningful error > >>>>message. > >>>> > >>>> - Add back support for aliases to aliases (broken in 5c9fcb02e), > >>>>while still ensuring that aliases point to either the correct actual > >>>>flavor or alias flavor, and not something else like a typeattribute. > >>>> > >>>> Signed-off-by: Steve Lawrence <slawre...@tresys.com> > >>> > >>> > >>> I didn't even think of the case of an alias of an alias. Applied. > >>> > >>> Thanks, > >>> Jim > >> > >> Hello, > >> This patch broke secilc's test case. From secilc/ directory: > >> > >> $ ./secilc test/policy.cil > >> cat0 is not a category. Only categories are allowed in > >> categoryorder statements > >> Failed to compile cildb: -1 > >> > >> cat0 is defined as a categoryalias in secilc/test/policy.cil and is > >> used in "(categoryorder (cat0 c1 c2 c3))". I do not have time right > >> now to investigate further what is causing the issue, but reverting > >> this commit (e501d3b6e8d2) fixes "make test". > > Looks like an incorrect error check in the recent patch I sent out. It > appears like typealiases are handled in many parts of the code and do > not rely on cil_resolve_name to convert to the actual, so typealias > appear to not be affected. But category and sensitivity resolution does > rely on cil_resolve_name to do the conversion. A patch is coming to fix > this. > > >> Nicolas > >> PS: if anyone is interested in the Travis-CI output of this bug, it is > >> available on https://travis-ci.org/fishilico/selinux/builds/238505788 > >> . > > > > There is still at least one typealias issue: > > > > for example, as said, i have: > > > > (typealias rpm_script_t) > > (typealiasactual rpm_script_t rpm.script.subj) > > > > where rpm.script.subj is a valid declared type > > > > However when i, in addition and by mistake, try to declare rpm.script.subj > > typealias as per: > > > > (typealias rpm.script.subj) > > This is illegal syntax. Just like you cannot define a type as > > (type foo.bar.baz) > > Instead, you need to use blocks if you want to namespace a typealias. > > (block rpm > (block script > (typealias subj) > ) > ) > > > > > then it does not return: Re-declaration of typealias rpm.script.subj > > Re-declaration checks happen in resolution, but since this is a syntax > error it never even gets that far to do the check. The below error is > expected. Makes sense, thanks > > > > > instead it returns: > > > > Invalid character "." in rpm.script.subj > > Invalid name > > Failed to create node > > > > This does "work" however with non-name spaced types: > > > > (type a) > > (typealias b) > > (typealiasactual b a) > > (typealias a) > > This causes an error for me: Yes, that is what i mean with "does work". It fails as expected but the error message makes sense. Alright thanks that settles that then > > Re-declaration of typealias a > Failed to create node > Bad typealias declaration at policy.cil:13
Re: [PATCH] libsepol/cil: better error message with duplicate aliases + support aliases to aliases
gt;> *current, void *extra_args, enu
> >> alias = (struct cil_alias *)alias_datum;
> >> if (alias->actual != NULL) {
> >> - cil_log(CIL_ERR, "Alias cannot bind more than one
> >> value\n");
> >> + cil_log(CIL_ERR, "%s %s cannot bind more than one
> >> value\n", cil_node_to_string(NODE(alias_datum)), alias_datum->name);
> >> rc = SEPOL_ERR;
> >> goto exit;
> >> }
> >> @@ -4122,6 +4122,34 @@ static int __cil_resolve_name_helper(struct cil_db
> >> *db, struct cil_tree_node *no
> >> int cil_resolve_name(struct cil_tree_node *ast_node, char *name, enum
> >> cil_sym_index sym_index, void *extra_args, struct cil_symtab_datum **datum)
> >> {
> >> int rc = SEPOL_ERR;
> >> + struct cil_tree_node *node = NULL;
> >> +
> >> + rc = cil_resolve_name_keep_aliases(ast_node, name, sym_index,
> >> extra_args, datum);
> >> + if (rc != SEPOL_ERR) {
> >> + goto exit;
> >> + }
> >> +
> >> + /* If this datum is an alias, then return the actual node
> >> +* This depends on aliases already being processed
> >> +*/
> >> + node = NODE(*datum);
> >> + if (node->flavor == CIL_TYPEALIAS || node->flavor == CIL_SENSALIAS
> >> + || node->flavor == CIL_CATALIAS) {
> >> + struct cil_alias *alias = (struct cil_alias *)(*datum);
> >> + if (alias->actual) {
> >> + *datum = alias->actual;
> >> + }
> >> + }
> >> +
> >> + rc = SEPOL_OK;
> >> +
> >> +exit:
> >> + return rc;
> >> +}
> >> +
> >> +int cil_resolve_name_keep_aliases(struct cil_tree_node *ast_node, char
> >> *name, enum cil_sym_index sym_index, void *extra_args, struct
> >> cil_symtab_datum **datum)
> >> +{
> >> + int rc = SEPOL_ERR;
> >> struct cil_args_resolve *args = extra_args;
> >> struct cil_db *db = args->db;
> >> struct cil_tree_node *node = NULL;
> >> @@ -4208,20 +4236,6 @@ exit:
> >> *datum = NULL;
> >> }
> >> - if (*datum != NULL) {
> >> - /* If this datum is an alias, then return the actual node
> >> -* This depends on aliases already being processed
> >> -*/
> >> - node = NODE(*datum);
> >> - if (node->flavor == CIL_TYPEALIAS || node->flavor ==
> >> CIL_SENSALIAS
> >> - || node->flavor == CIL_CATALIAS) {
> >> - struct cil_alias *alias = (struct cil_alias
> >> *)(*datum);
> >> - if (alias->actual) {
> >> - *datum = alias->actual;
> >> - }
> >> - }
> >> - }
> >> -
> >> args->last_resolved_name = name;
> >> return rc;
> >> diff --git a/libsepol/cil/src/cil_resolve_ast.h
> >> b/libsepol/cil/src/cil_resolve_ast.h
> >> index 82c8ea3..1d971fd 100644
> >> --- a/libsepol/cil/src/cil_resolve_ast.h
> >> +++ b/libsepol/cil/src/cil_resolve_ast.h
> >> @@ -99,5 +99,6 @@ int cil_resolve_tunif(struct cil_tree_node *current,
> >> void *extra_args);
> >> int cil_resolve_ast(struct cil_db *db, struct cil_tree_node *current);
> >> int cil_resolve_name(struct cil_tree_node *ast_node, char *name, enum
> >> cil_sym_index sym_index, void *extra_args, struct cil_symtab_datum
> >> **datum);
> >> +int cil_resolve_name_keep_aliases(struct cil_tree_node *ast_node, char
> >> *name, enum cil_sym_index sym_index, void *extra_args, struct
> >> cil_symtab_datum **datum);
> >> #endif /* CIL_RESOLVE_AST_H_ */
> >>
> >
> >
> > --
> > James Carter <jwca...@tycho.nsa.gov>
> > National Security Agency
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
libsepol segfaults with typealias and typealiasactual
I have a typealias/typealiasactual in dssp2-standard at: https://github.com/DefenSec/dssp2-standard/blob/master/policy/system/rpm.cil#L18 This *works* However now i want to additionally associate "unconfined.user.subj" with "rpm_script_t" So i created a module: echo "(typealiasesactual rpm_script_t unconfined.user.subj)" > mytest.cil && semodule -i mytest.cil it returns (something along those lines): "subj is not an alias" however it seems as though the module did install. I cannot think of any simple way to determine whether it works as I cannot find any "seinfo --typealias" or sesearch "--typealiases" Anyway libsepol segfaults when i try to play more with this So I tried the following (typeattribute rpm_script_aliases_type_attribute) (typeattributeset rpm_script_aliases_type_attribute rpm.script.subj) (typeattributeset rpm_script_aliases_type_attribute unconfined.user.subj) (typealias rpm_script_t) (typealiasactual rpm_script_t rpm_script_aliases_type_attribute) This also return incoherent messages something like "invalid "." in ...", but it seems to install and after that everything just segfaults (libsepol), untill i remove my local customizations I dont know a better way to explain this but looks to me theres a serious bug in how typealiases are handled by libsepol: https://www.youtube.com/watch?v=qe-vqieu2jg -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: Fedora COPR repositories with builds of latest code
On Thu, May 25, 2017 at 11:40:49AM +0200, Petr Lautrbach wrote: > On 05/25/2017 07:44 AM, Dominick Grift wrote: > > On Wed, May 24, 2017 at 04:40:55PM -0400, Stephen Smalley wrote: > > > On Wed, 2017-05-24 at 16:53 +0200, Dominick Grift wrote: > > > > On Wed, May 24, 2017 at 04:33:16PM +0200, Dominick Grift wrote: > > > > > On Wed, May 24, 2017 at 04:22:08PM +0200, Petr Lautrbach wrote: > > > > > > For the motivation see > > > > > > https://marc.info/?l=selinux=149435307518336=2 > > > > > > > > > > Thanks! I enabled the one with Fedora patches because i need > > > > > python3 support for setools4 > > > > > > > > > > This should allow me to enable extended_socket_class functionality > > > > > and test it. > > > > > > > > > > I hope this repository will be maintained consistently so that it > > > > > can be useful > > > > > > > > I just enabled the extended_socket_class capability and in seinfo -- > > > > polcap -x it currently shows up as "redhat1": > > > > > > > > # seinfo --polcap -x > > > > > > > > Polcap: 3 > > > > policycap network_peer_controls; > > > > policycap open_perms; > > > > policycap redhat1; > > > > > > > > I know the redhat1 polcap is re-used but not sure if this expected to > > > > return like that... > > > > > > Maybe setools4 hasn't been rebuilt to use the updated libsepol, or has > > > its own internal table of the policy capability string names? > > > > thanks , yes thats the case (former) > > I will update scripts to rebuild setools together with selinux sources and > provide setools builds in copr repos Thank you > > > > > > > > > > > > > > > > > > > > > > > > > > > I've restarted building of Fedora packages based on latest > > > > > > SELinux userspace code in Fedora COPR. Packages are built using > > > > > > the https://gitlab.com/bachradsusi/selinux-rpm project. > > > > > > > > > > > > There is a new selinux.spec [1] file which allows to build all > > > > > > Fedora packages from one src.rpm and Makefile which makes the > > > > > > process simple. > > > > > > > > > > > > Currently there are two COPR projects: > > > > > > > > > > > > * https://copr.fedorainfracloud.org/coprs/plautrba/selinux-fedora > > > > > > / > > > > > > > > > > > > This is built with Python3 support based on Fedora patches which > > > > > > are rebased against latest upstream code. > > > > > > > > > > > > > > > > > > * https://copr.fedorainfracloud.org/coprs/plautrba/selinux-SELinu > > > > > > xProject/ > > > > > > > > > > > > This is based on pure upstream sources and without Python 3. > > > > > > > > > > > > > > > > > > Currently I run copr builds manually but the plan is to make it > > > > > > fully automated. > > > > > > > > > > > > > > > > > > Let me know if you find it useful or if you have ideas, comments > > > > > > and so on. > > > > > > > > > > > > > > > > > > [1] https://gitlab.com/bachradsusi/selinux-rpm/blob/master/selinu > > > > > > x.spec > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > Petr > > > > > > > > > > -- > > > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B > > > > > 6B02 > > > > > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6 > > > > > B02 > > > > > Dominick Grift > > > > > > > > > > > > > > > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: ioctl help
On Wed, May 24, 2017 at 04:11:44PM -0400, Stephen Smalley wrote: > On Wed, 2017-05-24 at 14:08 +0200, Dominick Grift wrote: > > I was looking again at ioctl whitelisting, and excuse me if I > > overlooked some documentation, but I am having a hard time > > implementing this. > > what I did was I just wanted to basically test blacklisting a single > > ioctl (no particular one) > > > > So i looked into androids sepolicy and just picked a semi-random > > ioctl from their "https://android.googlesource.com/platform/system/se > > policy/+/master/public/ioctl_defines" > > > > for example: PHONE_CAPABILITIES_CHECK 0x40087182 > > > > However the xpermissions statement only allows 0x to 0x when > > i tried: (xpermission alg_socket_ioctl (ioctl alg_socket (not > > (0x40087182 > > > > My question is how do i convert these to something i can use with the > > xpermission statement in CIL, and why can seandroid sepolicy get away > > with using 0x12345678 where i have to use 0x1234? I could not find > > any scripts that converts these in the android tree. > > FWIW, I added a simple test of ioctl whitelisting to the selinux- > testsuite, although that was done in source policy and depends on the > binary module format support for xperms. > > With regard to your question though, only the low 16 bits of the ioctl > value (the type/driver and number/function fields) are actually used; > the upper 16 bits encode the direction (read/write) and size of any > argument to the ioctl and are therefore not relevant for whitelisting. > So you can just use 0x7182. checkpolicy just ignores the upper bits, > which I guess is convenient so that they can use ioctl macro lists > generated from kernel header definitions, and Android builds by using > checkpolicy -C to convert policy.conf to CIL. Thanks. I considered that but then I thought I saw various different ioctls with the same last 16 bits so that got me confused -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: Fedora COPR repositories with builds of latest code
On Wed, May 24, 2017 at 04:40:55PM -0400, Stephen Smalley wrote: > On Wed, 2017-05-24 at 16:53 +0200, Dominick Grift wrote: > > On Wed, May 24, 2017 at 04:33:16PM +0200, Dominick Grift wrote: > > > On Wed, May 24, 2017 at 04:22:08PM +0200, Petr Lautrbach wrote: > > > > For the motivation see > > > > https://marc.info/?l=selinux=149435307518336=2 > > > > > > Thanks! I enabled the one with Fedora patches because i need > > > python3 support for setools4 > > > > > > This should allow me to enable extended_socket_class functionality > > > and test it. > > > > > > I hope this repository will be maintained consistently so that it > > > can be useful > > > > I just enabled the extended_socket_class capability and in seinfo -- > > polcap -x it currently shows up as "redhat1": > > > > # seinfo --polcap -x > > > > Polcap: 3 > > policycap network_peer_controls; > > policycap open_perms; > > policycap redhat1; > > > > I know the redhat1 polcap is re-used but not sure if this expected to > > return like that... > > Maybe setools4 hasn't been rebuilt to use the updated libsepol, or has > its own internal table of the policy capability string names? thanks , yes thats the case (former) > > > > > > > > > > > > > > I've restarted building of Fedora packages based on latest > > > > SELinux userspace code in Fedora COPR. Packages are built using > > > > the https://gitlab.com/bachradsusi/selinux-rpm project. > > > > > > > > There is a new selinux.spec [1] file which allows to build all > > > > Fedora packages from one src.rpm and Makefile which makes the > > > > process simple. > > > > > > > > Currently there are two COPR projects: > > > > > > > > * https://copr.fedorainfracloud.org/coprs/plautrba/selinux-fedora > > > > / > > > > > > > > This is built with Python3 support based on Fedora patches which > > > > are rebased against latest upstream code. > > > > > > > > > > > > * https://copr.fedorainfracloud.org/coprs/plautrba/selinux-SELinu > > > > xProject/ > > > > > > > > This is based on pure upstream sources and without Python 3. > > > > > > > > > > > > Currently I run copr builds manually but the plan is to make it > > > > fully automated. > > > > > > > > > > > > Let me know if you find it useful or if you have ideas, comments > > > > and so on. > > > > > > > > > > > > [1] https://gitlab.com/bachradsusi/selinux-rpm/blob/master/selinu > > > > x.spec > > > > > > > > > > > > Thanks, > > > > > > > > Petr > > > > > > -- > > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B > > > 6B02 > > > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6 > > > B02 > > > Dominick Grift > > > > > > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: Fedora COPR repositories with builds of latest code
On Wed, May 24, 2017 at 04:33:16PM +0200, Dominick Grift wrote: > On Wed, May 24, 2017 at 04:22:08PM +0200, Petr Lautrbach wrote: > > For the motivation see > > https://marc.info/?l=selinux=149435307518336=2 > > Thanks! I enabled the one with Fedora patches because i need python3 support > for setools4 > > This should allow me to enable extended_socket_class functionality and test > it. > > I hope this repository will be maintained consistently so that it can be > useful I just enabled the extended_socket_class capability and in seinfo --polcap -x it currently shows up as "redhat1": # seinfo --polcap -x Polcap: 3 policycap network_peer_controls; policycap open_perms; policycap redhat1; I know the redhat1 polcap is re-used but not sure if this expected to return like that... > > > > > I've restarted building of Fedora packages based on latest > > SELinux userspace code in Fedora COPR. Packages are built using > > the https://gitlab.com/bachradsusi/selinux-rpm project. > > > > There is a new selinux.spec [1] file which allows to build all > > Fedora packages from one src.rpm and Makefile which makes the > > process simple. > > > > Currently there are two COPR projects: > > > > * https://copr.fedorainfracloud.org/coprs/plautrba/selinux-fedora/ > > > > This is built with Python3 support based on Fedora patches which > > are rebased against latest upstream code. > > > > > > * https://copr.fedorainfracloud.org/coprs/plautrba/selinux-SELinuxProject/ > > > > This is based on pure upstream sources and without Python 3. > > > > > > Currently I run copr builds manually but the plan is to make it > > fully automated. > > > > > > Let me know if you find it useful or if you have ideas, comments and so on. > > > > > > [1] https://gitlab.com/bachradsusi/selinux-rpm/blob/master/selinux.spec > > > > > > Thanks, > > > > Petr > > -- > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > Dominick Grift -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: Fedora COPR repositories with builds of latest code
On Wed, May 24, 2017 at 04:22:08PM +0200, Petr Lautrbach wrote: > For the motivation see > https://marc.info/?l=selinux=149435307518336=2 Thanks! I enabled the one with Fedora patches because i need python3 support for setools4 This should allow me to enable extended_socket_class functionality and test it. I hope this repository will be maintained consistently so that it can be useful > > I've restarted building of Fedora packages based on latest > SELinux userspace code in Fedora COPR. Packages are built using > the https://gitlab.com/bachradsusi/selinux-rpm project. > > There is a new selinux.spec [1] file which allows to build all > Fedora packages from one src.rpm and Makefile which makes the > process simple. > > Currently there are two COPR projects: > > * https://copr.fedorainfracloud.org/coprs/plautrba/selinux-fedora/ > > This is built with Python3 support based on Fedora patches which > are rebased against latest upstream code. > > > * https://copr.fedorainfracloud.org/coprs/plautrba/selinux-SELinuxProject/ > > This is based on pure upstream sources and without Python 3. > > > Currently I run copr builds manually but the plan is to make it > fully automated. > > > Let me know if you find it useful or if you have ideas, comments and so on. > > > [1] https://gitlab.com/bachradsusi/selinux-rpm/blob/master/selinux.spec > > > Thanks, > > Petr -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
ioctl help
I was looking again at ioctl whitelisting, and excuse me if I overlooked some documentation, but I am having a hard time implementing this. what I did was I just wanted to basically test blacklisting a single ioctl (no particular one) So i looked into androids sepolicy and just picked a semi-random ioctl from their "https://android.googlesource.com/platform/system/sepolicy/+/master/public/ioctl_defines; for example: PHONE_CAPABILITIES_CHECK 0x40087182 However the xpermissions statement only allows 0x to 0x when i tried: (xpermission alg_socket_ioctl (ioctl alg_socket (not (0x40087182 My question is how do i convert these to something i can use with the xpermission statement in CIL, and why can seandroid sepolicy get away with using 0x12345678 where i have to use 0x1234? I could not find any scripts that converts these in the android tree. -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: RHEL 7.3 : httpd : type=SELINUX_ERR op=security_bounded_transition seresult=denied
On Mon, May 22, 2017 at 08:23:50PM +0200, Dominick Grift wrote: > On Mon, May 22, 2017 at 02:18:29PM -0400, Stephen Smalley wrote: > > On Mon, 2017-05-22 at 09:29 -0700, Chris O'Neil wrote: > > > Hi, running latest RHEL 7.3 ... struggling with an SELinux issue > > > related > > > to Apache httpd that I just can't figure out. I have always been > > > able > > > to tune policy or alter a boolean, this one has me stumped! > > > > > > What I am trying to do: I am trying to deploy a simple, 3 line CGI > > > script in /var/www/cgi-bin/. Runs fine with enforcement disabled > > > (see > > > output below). My custom policy for Apache (see below) comes from my > > > EL6 environment. > > > > > > The normal setroubleshooting tools don't help, as there is only a > > > single > > > line in audit.log (of type=SELINUX_ERR) > > > > > > This is not happening on latest RHEL 6.9 ... > > > > > > Might be related to systemd? I don't see any "NoNewPrivileges" > > > directives inside /etc/systemd/ though ... weird! > > > > Is the filesystem mounted nosuid? > > If selinux also uses that message for that scenario then i find that > confusing since the message, to me, implies that the issue can be find by > adding a type bounds, but i don't think that would work for nosuid mounted > slices s/find/fixed > > > > > > > > Many thanks for your help! > > > -chris > > > > > > > > > # > > > ### > > > # With enforcement disabled ... all is good (as expected) > > > # > > > ### > > > > > > # ls -laZ /var/www/cgi-bin/ > > > drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 . > > > drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 .. > > > -rwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 > > > ok.cgi > > > > > > # setenforce 0 > > > # systemctl restart httpd.service > > > $ curl localhost/cgi-bin/ok.cgi > > > OK > > > > > > > > > # > > > ### > > > # With enforcement enabled ... CGI script fails, all you find is a > > > # single deny in /var/log/audit/audit.log > > > # > > > ### > > > > > > # setenforce 1 > > > # systemctl restart httpd.service > > > > > > # getenforce > > > Enforcing > > > > > > $ curl localhost/cgi-bin/ok.cgi > > > 500 Server ErrorServer > > > Error > > > > > > # tail /var/log/audit/audit.log | grep denied > > > type=SELINUX_ERR msg=audit(1495468154.591:121695): > > > op=security_bounded_transition seresult=denied > > > oldcontext=system_u:system_r:httpd_t:s0 > > > newcontext=system_u:system_r:httpd_sys_script_t:s0 > > > > > > > > > # > > > ### > > > # System details ... > > > # > > > ### > > > > > > # uname -r > > > 3.10.0-514.16.1.el7.x86_64 > > > > > > # cat /etc/redhat-release > > > Red Hat Enterprise Linux Server release 7.3 (Maipo) > > > > > > # sestatus > > > SELinux status: enabled > > > SELinuxfs mount:/sys/fs/selinux > > > SELinux root directory: /etc/selinux > > > Loaded policy name: targeted > > > Current mode: enforcing > > > Mode from config file: enforcing > > > Policy MLS status: enabled > > > Policy deny_unknown status: allowed > > > Max kernel policy version: 28 > > > > > > # find /etc/ -type f | xargs grep NoNewPrivileges > > > [NO OUTPUT] > > > > > > # getsebool -a | grep httpd_ > > > httpd_anon_write --> on > > > httpd_builtin_scripting --> on > > > httpd_can_check_spam --> off > > > httpd_can_connect_ftp --> off > > > httpd_can_connect_ldap --> off > > > httpd_can_connect_mythtv --> off > > > httpd_can_connect_zabbix --> off > > > httpd_ca
Re: RHEL 7.3 : httpd : type=SELINUX_ERR op=security_bounded_transition seresult=denied
mod_auth_ntlm_winbind --> off
> > httpd_mod_auth_pam --> off
> > httpd_read_user_content --> on
> > httpd_run_ipa --> off
> > httpd_run_preupgrade --> off
> > httpd_run_stickshift --> off
> > httpd_serve_cobbler_files --> off
> > httpd_setrlimit --> off
> > httpd_ssi_exec --> off
> > httpd_sys_script_anon_write --> off
> > httpd_tmp_exec --> off
> > httpd_tty_comm --> on
> > httpd_unified --> on
> > httpd_use_cifs --> off
> > httpd_use_fusefs --> off
> > httpd_use_gpg --> off
> > httpd_use_nfs --> off
> > httpd_use_openstack --> off
> > httpd_use_sasl --> off
> > httpd_verify_dns --> off
> >
> >
> > # THIS IS MY GENERIC APACHE TE FILE FROM EL6 ...
> >
> > # cat myapache.te
> > module myapache 0.4;
> >
> > require {
> > type httpd_t;
> > type httpd_sys_script_t;
> > type http_port_t;
> > type mysqld_port_t;
> > type rpm_var_cache_t;
> > type kernel_t;
> > class process { setpgid transition };
> > class system module_request;
> > class tcp_socket name_connect;
> > class dir { read search open getattr };
> > class file { open read getattr };
> > }
> >
> > allow httpd_t rpm_var_cache_t:dir { read search open getattr };
> > allow httpd_t rpm_var_cache_t:file { read getattr open } ;
> > allow httpd_t mysqld_port_t:tcp_socket name_connect;
> > allow httpd_sys_script_t self:process setpgid;
> > allow httpd_sys_script_t http_port_t:tcp_socket name_connect;
> > allow httpd_sys_script_t kernel_t:system module_request;
> >
> > #type=SELINUX_ERR msg=audit(1495467001.822:84934):
> > op=security_bounded_transition seresult=denied
> > oldcontext=system_u:system_r:httpd_t:s0
> > newcontext=system_u:system_r:httpd_sys_script_t:s0
> > # THIS STILL DOES NOT WORK! SYSTEMD ISSUE?
> > allow httpd_t httpd_sys_script_t:process transition;
> >
> >
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: RHEL 7.3 : httpd : type=SELINUX_ERR op=security_bounded_transition seresult=denied
On Mon, May 22, 2017 at 10:16:55AM -0700, Chris O'Neil wrote: > > > On 05/22/2017 09:58 AM, Dominick Grift wrote: > > On Mon, May 22, 2017 at 09:29:10AM -0700, Chris O'Neil wrote: > >> Hi, running latest RHEL 7.3 ... struggling with an SELinux issue related > >> to Apache httpd that I just can't figure out. I have always been able > >> to tune policy or alter a boolean, this one has me stumped! > >> > >> What I am trying to do: I am trying to deploy a simple, 3 line CGI > >> script in /var/www/cgi-bin/. Runs fine with enforcement disabled (see > >> output below). My custom policy for Apache (see below) comes from my > >> EL6 environment. > >> > >> The normal setroubleshooting tools don't help, as there is only a single > >> line in audit.log (of type=SELINUX_ERR) > >> > >> This is not happening on latest RHEL 6.9 ... > >> > >> Might be related to systemd? I don't see any "NoNewPrivileges" > >> directives inside /etc/systemd/ though ... weird! > > > > > try grepping /usr/lib/systemd as well > > also do you have "mod_selinux" enabled? because that requires a type bounds > > as well AFAIK > > Dominick, I did find the "NoNewPrivileges" directive inside of > /usr/lib/systemd/system/systemd-importd.service ... commented it out, > rebooted just to be safe ... no luck ... same problem as before, same > message in /var/log/audit/audit.log. Also tried changing the value from > "Yes" to "No" and rebooting, that didn't help. Yes that only applies to systemd-importd (which i suppose no one uses at least not with selinux enabled) > > $ curl localhost/cgi-bin/ok.cgi > 500 Server ErrorServer > Error > > # tail /var/log/audit/audit.log | grep denied > type=SELINUX_ERR msg=audit(1495473331.188:183): > op=security_bounded_transition seresult=denied > oldcontext=system_u:system_r:httpd_t:s0 > newcontext=system_u:system_r:httpd_sys_script_t:s0 > > Confirmed I do not have "mod_selinux" enabled ... this is a pretty > vanilla deployment of RHEL 7 and Apache httpd Are you using any other "exotic"/non-default apache modules? (i suppose not since you already said its pretty vanilla) > > Thanks! > -chris > > > > >> > >> Many thanks for your help! > >> -chris > >> > >> > >> > >> # With enforcement disabled ... all is good (as expected) > >> > >> > >> # ls -laZ /var/www/cgi-bin/ > >> drwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 . > >> drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 .. > >> -rwxr-xr-x. root root system_u:object_r:httpd_sys_script_exec_t:s0 ok.cgi > >> > >> # setenforce 0 > >> # systemctl restart httpd.service > >> $ curl localhost/cgi-bin/ok.cgi > >> OK > >> > >> > >> > >> # With enforcement enabled ... CGI script fails, all you find is a > >> # single deny in /var/log/audit/audit.log > >> > >> > >> # setenforce 1 > >> # systemctl restart httpd.service > >> > >> # getenforce > >> Enforcing > >> > >> $ curl localhost/cgi-bin/ok.cgi > >> 500 Server ErrorServer > >> Error > >> > >> # tail /var/log/audit/audit.log | grep denied > >> type=SELINUX_ERR msg=audit(1495468154.591:121695): > >> op=security_bounded_transition seresult=denied > >> oldcontext=system_u:system_r:httpd_t:s0 > >> newcontext=system_u:system_r:httpd_sys_script_t:s0 > >> > >> > >> > >> # System details ... > >> > >> > >> # uname -r > >> 3.10.0-514.16.1.el7.x86_64 > >> > >> # cat /etc/redhat-release > >> Red Hat Enterprise Linux Server release 7.3 (Maipo) > >> > >> # sestatus > >> SELinux status: enabled > >> SELinuxfs mount:/sys/fs/selinux > >> SELinux root directory: /etc/selinux > >> Loaded policy name: targeted > >> Current mode: enforcing > >> Mode
Re: RHEL 7.3 : httpd : type=SELINUX_ERR op=security_bounded_transition seresult=denied
type httpd_sys_script_t;
> type http_port_t;
> type mysqld_port_t;
> type rpm_var_cache_t;
> type kernel_t;
> class process { setpgid transition };
> class system module_request;
> class tcp_socket name_connect;
> class dir { read search open getattr };
> class file { open read getattr };
> }
>
> allow httpd_t rpm_var_cache_t:dir { read search open getattr };
> allow httpd_t rpm_var_cache_t:file { read getattr open } ;
> allow httpd_t mysqld_port_t:tcp_socket name_connect;
> allow httpd_sys_script_t self:process setpgid;
> allow httpd_sys_script_t http_port_t:tcp_socket name_connect;
> allow httpd_sys_script_t kernel_t:system module_request;
>
> #type=SELINUX_ERR msg=audit(1495467001.822:84934):
> op=security_bounded_transition seresult=denied
> oldcontext=system_u:system_r:httpd_t:s0
> newcontext=system_u:system_r:httpd_sys_script_t:s0
> # THIS STILL DOES NOT WORK! SYSTEMD ISSUE?
> allow httpd_t httpd_sys_script_t:process transition;
>
>
>
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: Announcing SPAN: SELinux Policy Analysis Notebook
On Tue, May 09, 2017 at 06:47:55PM +0200, Dominick Grift wrote: > On Tue, May 09, 2017 at 06:15:43PM +0200, Dominick Grift wrote: > > On Tue, May 09, 2017 at 11:21:23AM -0400, Karl MacMillan wrote: > > > > > > > On May 8, 2017, at 4:40 PM, Dominick Grift <dac.overr...@gmail.com> > > > > wrote: > > > > > > > > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote: > > > >> > > > >>> On May 8, 2017, at 3:49 PM, Dominick Grift <dac.overr...@gmail.com> > > > >>> wrote: > > > >>> > > > >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > > > >>>> > > > >>>>> > > > >>>> > > > >>>> I think it’s best to think of these as having three basic layers: > > > >>>> > > > >>>> 1. Basic tools for SELinux policy analysis in Jupyter - these are > > > >>>> usable for any policy and make no assumptions about the presence of > > > >>>> any types, attributes, object classes, or permissions. So things > > > >>>> like the rule searching and information flow analysis fit into this > > > >>>> group. This is a large part of the value of SPAN. > > > >>>> > > > >>>> 2. Higher-level policy analysis methods - these are things like the > > > >>>> domain_types method and the domain / type summaries. These make some > > > >>>> minimal assumptions about attributes like domain. I’ll just mention > > > >>>> that these assumptions are very minimal and have been around for a > > > >>>> _long_ time. Domain long pre-dates the reference policy, for > > > >>>> example. More than attributes this layer is tied to the Linux object > > > >>>> classes and permissions. > > > >>>> > > > >>>> 3. Example notebooks - the two example notebooks are just that - > > > >>>> examples. They probably provide a useful starting point, but as Josh > > > >>>> points out, should simply be modified for your specific use case. > > > >>>> > > > >>>> So the question, then, is should the second layer (the higher-level > > > >>>> policy analysis methods) be made configurable. Honestly I think it > > > >>>> would be more work than just creating your own versions for a policy > > > >>>> that breaks the assumptions. To me, that’s the great advantage of > > > >>>> this versus other analysis tools. It’s so simple to create quick > > > >>>> tools that meet your needs. And given that the vast majority of > > > >>>> Linux and Android systems meet the assumptions I think that this is > > > >>>> a reasonable approach. > > > >>> > > > >>> I don't think it will work with android. Some of it maybe but not all > > > >>> of it. for example the source functionality appends "modules" to the > > > >>> search path. So i suspect that will break that functionality for > > > >>> Android. > > > >> > > > >> We’ve not tested it for Android policies so I’m sure there will be > > > >> some breakage. But I hope it will be fixed to work by us or someone > > > >> soon. > > > >> > > > >>> Thank you for giving me your opinion. At least now I know where I > > > >>> stand. > > > >> > > > >> Where you stand? I’m not certain what you mean and was not trying to > > > >> say something about you personally. > > > > > > > > I didnt take it personal, That is not what I meant. To me SELinux is > > > > bigger then any single policy be it refpolicy, sepolicy, or dssp > > > > The perfect tool would support any policy (setools goes a long way > > > > there). From your comments I sensed that you might not fully agree with > > > > that or that you might not have the ambition for SPAN to be perfect. > > > > What I am saying is that after your comment I no longer have any > > > > illusions that SPAN will ever be perfect (or close to perfect) > > > > > > > > > > Shrug. SELinux is “bigger” than the current set of object classes and > > > access vectors
Re: Announcing SPAN: SELinux Policy Analysis Notebook
On Tue, May 09, 2017 at 06:15:43PM +0200, Dominick Grift wrote: > On Tue, May 09, 2017 at 11:21:23AM -0400, Karl MacMillan wrote: > > > > > On May 8, 2017, at 4:40 PM, Dominick Grift <dac.overr...@gmail.com> wrote: > > > > > > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote: > > >> > > >>> On May 8, 2017, at 3:49 PM, Dominick Grift <dac.overr...@gmail.com> > > >>> wrote: > > >>> > > >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > > >>>> > > >>>>> > > >>>> > > >>>> I think it’s best to think of these as having three basic layers: > > >>>> > > >>>> 1. Basic tools for SELinux policy analysis in Jupyter - these are > > >>>> usable for any policy and make no assumptions about the presence of > > >>>> any types, attributes, object classes, or permissions. So things like > > >>>> the rule searching and information flow analysis fit into this group. > > >>>> This is a large part of the value of SPAN. > > >>>> > > >>>> 2. Higher-level policy analysis methods - these are things like the > > >>>> domain_types method and the domain / type summaries. These make some > > >>>> minimal assumptions about attributes like domain. I’ll just mention > > >>>> that these assumptions are very minimal and have been around for a > > >>>> _long_ time. Domain long pre-dates the reference policy, for example. > > >>>> More than attributes this layer is tied to the Linux object classes > > >>>> and permissions. > > >>>> > > >>>> 3. Example notebooks - the two example notebooks are just that - > > >>>> examples. They probably provide a useful starting point, but as Josh > > >>>> points out, should simply be modified for your specific use case. > > >>>> > > >>>> So the question, then, is should the second layer (the higher-level > > >>>> policy analysis methods) be made configurable. Honestly I think it > > >>>> would be more work than just creating your own versions for a policy > > >>>> that breaks the assumptions. To me, that’s the great advantage of this > > >>>> versus other analysis tools. It’s so simple to create quick tools that > > >>>> meet your needs. And given that the vast majority of Linux and Android > > >>>> systems meet the assumptions I think that this is a reasonable > > >>>> approach. > > >>> > > >>> I don't think it will work with android. Some of it maybe but not all > > >>> of it. for example the source functionality appends "modules" to the > > >>> search path. So i suspect that will break that functionality for > > >>> Android. > > >> > > >> We’ve not tested it for Android policies so I’m sure there will be some > > >> breakage. But I hope it will be fixed to work by us or someone soon. > > >> > > >>> Thank you for giving me your opinion. At least now I know where I stand. > > >> > > >> Where you stand? I’m not certain what you mean and was not trying to say > > >> something about you personally. > > > > > > I didnt take it personal, That is not what I meant. To me SELinux is > > > bigger then any single policy be it refpolicy, sepolicy, or dssp > > > The perfect tool would support any policy (setools goes a long way > > > there). From your comments I sensed that you might not fully agree with > > > that or that you might not have the ambition for SPAN to be perfect. > > > What I am saying is that after your comment I no longer have any > > > illusions that SPAN will ever be perfect (or close to perfect) > > > > > > > Shrug. SELinux is “bigger” than the current set of object classes and > > access vectors or the components of the security context. Yet we still have > > to write policy using those. Abstraction is a useful tool, but too much > > abstraction interferes with getting work done clearly. > > > > Ultimately SPAN has to make some assumptions about how policy works to do > > any higher-level analysis (a problem that SETools doesn’t really have > > because it doesn’t do much of the higher-level analysis that I’m talking &
Re: Announcing SPAN: SELinux Policy Analysis Notebook
On Tue, May 09, 2017 at 11:21:23AM -0400, Karl MacMillan wrote: > > > On May 8, 2017, at 4:40 PM, Dominick Grift <dac.overr...@gmail.com> wrote: > > > > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote: > >> > >>> On May 8, 2017, at 3:49 PM, Dominick Grift <dac.overr...@gmail.com> wrote: > >>> > >>> On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > >>>> > >>>>> > >>>> > >>>> I think it’s best to think of these as having three basic layers: > >>>> > >>>> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable > >>>> for any policy and make no assumptions about the presence of any types, > >>>> attributes, object classes, or permissions. So things like the rule > >>>> searching and information flow analysis fit into this group. This is a > >>>> large part of the value of SPAN. > >>>> > >>>> 2. Higher-level policy analysis methods - these are things like the > >>>> domain_types method and the domain / type summaries. These make some > >>>> minimal assumptions about attributes like domain. I’ll just mention that > >>>> these assumptions are very minimal and have been around for a _long_ > >>>> time. Domain long pre-dates the reference policy, for example. More than > >>>> attributes this layer is tied to the Linux object classes and > >>>> permissions. > >>>> > >>>> 3. Example notebooks - the two example notebooks are just that - > >>>> examples. They probably provide a useful starting point, but as Josh > >>>> points out, should simply be modified for your specific use case. > >>>> > >>>> So the question, then, is should the second layer (the higher-level > >>>> policy analysis methods) be made configurable. Honestly I think it would > >>>> be more work than just creating your own versions for a policy that > >>>> breaks the assumptions. To me, that’s the great advantage of this versus > >>>> other analysis tools. It’s so simple to create quick tools that meet > >>>> your needs. And given that the vast majority of Linux and Android > >>>> systems meet the assumptions I think that this is a reasonable approach. > >>> > >>> I don't think it will work with android. Some of it maybe but not all of > >>> it. for example the source functionality appends "modules" to the search > >>> path. So i suspect that will break that functionality for Android. > >> > >> We’ve not tested it for Android policies so I’m sure there will be some > >> breakage. But I hope it will be fixed to work by us or someone soon. > >> > >>> Thank you for giving me your opinion. At least now I know where I stand. > >> > >> Where you stand? I’m not certain what you mean and was not trying to say > >> something about you personally. > > > > I didnt take it personal, That is not what I meant. To me SELinux is bigger > > then any single policy be it refpolicy, sepolicy, or dssp > > The perfect tool would support any policy (setools goes a long way there). > > From your comments I sensed that you might not fully agree with that or > > that you might not have the ambition for SPAN to be perfect. > > What I am saying is that after your comment I no longer have any illusions > > that SPAN will ever be perfect (or close to perfect) > > > > Shrug. SELinux is “bigger” than the current set of object classes and access > vectors or the components of the security context. Yet we still have to write > policy using those. Abstraction is a useful tool, but too much abstraction > interferes with getting work done clearly. > > Ultimately SPAN has to make some assumptions about how policy works to do any > higher-level analysis (a problem that SETools doesn’t really have because it > doesn’t do much of the higher-level analysis that I’m talking about). Making > that somewhat configurable is fine, but not at the cost of comprehensibility. > When we hit that point it’s better just to split the higher-level analysis > methods into different versions based the policy type. > > Either way, I’m open to including the customizations or separate code in SPAN. > > >> > >> I was not familiar with DSSP before (I’ve not done much with SELinux for a > >> while), but Josh pointed it o
Re: Announcing SPAN: SELinux Policy Analysis Notebook
On Mon, May 08, 2017 at 11:47:14PM +0200, Dominick Grift wrote: > On Mon, May 08, 2017 at 10:40:53PM +0200, Dominick Grift wrote: > > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote: > > > > > > > On May 8, 2017, at 3:49 PM, Dominick Grift <dac.overr...@gmail.com> > > > > wrote: > > > > > > > > On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > > > >> > > > >>> > > > >> > > > >> I think it’s best to think of these as having three basic layers: > > > >> > > > >> 1. Basic tools for SELinux policy analysis in Jupyter - these are > > > >> usable for any policy and make no assumptions about the presence of > > > >> any types, attributes, object classes, or permissions. So things like > > > >> the rule searching and information flow analysis fit into this group. > > > >> This is a large part of the value of SPAN. > > > >> > > > >> 2. Higher-level policy analysis methods - these are things like the > > > >> domain_types method and the domain / type summaries. These make some > > > >> minimal assumptions about attributes like domain. I’ll just mention > > > >> that these assumptions are very minimal and have been around for a > > > >> _long_ time. Domain long pre-dates the reference policy, for example. > > > >> More than attributes this layer is tied to the Linux object classes > > > >> and permissions. > > > >> > > > >> 3. Example notebooks - the two example notebooks are just that - > > > >> examples. They probably provide a useful starting point, but as Josh > > > >> points out, should simply be modified for your specific use case. > > > >> > > > >> So the question, then, is should the second layer (the higher-level > > > >> policy analysis methods) be made configurable. Honestly I think it > > > >> would be more work than just creating your own versions for a policy > > > >> that breaks the assumptions. To me, that’s the great advantage of this > > > >> versus other analysis tools. It’s so simple to create quick tools that > > > >> meet your needs. And given that the vast majority of Linux and Android > > > >> systems meet the assumptions I think that this is a reasonable > > > >> approach. > > > > > > > > I don't think it will work with android. Some of it maybe but not all > > > > of it. for example the source functionality appends "modules" to the > > > > search path. So i suspect that will break that functionality for > > > > Android. > > > > > > We’ve not tested it for Android policies so I’m sure there will be some > > > breakage. But I hope it will be fixed to work by us or someone soon. > > > > > > > Thank you for giving me your opinion. At least now I know where I stand. > > > > > > Where you stand? I’m not certain what you mean and was not trying to say > > > something about you personally. > > > > I didnt take it personal, That is not what I meant. To me SELinux is bigger > > then any single policy be it refpolicy, sepolicy, or dssp > > The perfect tool would support any policy (setools goes a long way there). > > From your comments I sensed that you might not fully agree with that or > > that you might not have the ambition for SPAN to be perfect. > > What I am saying is that after your comment I no longer have any illusions > > that SPAN will ever be perfect (or close to perfect) > > > > > > > > I was not familiar with DSSP before (I’ve not done much with SELinux for > > > a while), but Josh pointed it out to me. From looking at it very briefly > > > and thinking through the assumptions in SPAN my guess is that it would > > > take very few changes to make SPAN work with DSSP, even the source policy > > > stuff (which, honestly, is just a very small part mainly useful for > > > diffing constraints). > > > > > > And as a side note - it’s nice to see someone trying to write a policy > > > from scratch in CIL. Do you have a “domain” attribute or at least a > > > similar concept? > > > > Sure, but i cannot use "domain" for this because DSSP leverages namespaces. > > The equivalent in DSSP is "subj.subj_type_attribute" > > > > So if the configur
Re: Announcing SPAN: SELinux Policy Analysis Notebook
On Mon, May 08, 2017 at 10:40:53PM +0200, Dominick Grift wrote: > On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote: > > > > > On May 8, 2017, at 3:49 PM, Dominick Grift <dac.overr...@gmail.com> wrote: > > > > > > On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > > >> > > >>> > > >> > > >> I think it’s best to think of these as having three basic layers: > > >> > > >> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable > > >> for any policy and make no assumptions about the presence of any types, > > >> attributes, object classes, or permissions. So things like the rule > > >> searching and information flow analysis fit into this group. This is a > > >> large part of the value of SPAN. > > >> > > >> 2. Higher-level policy analysis methods - these are things like the > > >> domain_types method and the domain / type summaries. These make some > > >> minimal assumptions about attributes like domain. I’ll just mention that > > >> these assumptions are very minimal and have been around for a _long_ > > >> time. Domain long pre-dates the reference policy, for example. More than > > >> attributes this layer is tied to the Linux object classes and > > >> permissions. > > >> > > >> 3. Example notebooks - the two example notebooks are just that - > > >> examples. They probably provide a useful starting point, but as Josh > > >> points out, should simply be modified for your specific use case. > > >> > > >> So the question, then, is should the second layer (the higher-level > > >> policy analysis methods) be made configurable. Honestly I think it would > > >> be more work than just creating your own versions for a policy that > > >> breaks the assumptions. To me, that’s the great advantage of this versus > > >> other analysis tools. It’s so simple to create quick tools that meet > > >> your needs. And given that the vast majority of Linux and Android > > >> systems meet the assumptions I think that this is a reasonable approach. > > > > > > I don't think it will work with android. Some of it maybe but not all of > > > it. for example the source functionality appends "modules" to the search > > > path. So i suspect that will break that functionality for Android. > > > > We’ve not tested it for Android policies so I’m sure there will be some > > breakage. But I hope it will be fixed to work by us or someone soon. > > > > > Thank you for giving me your opinion. At least now I know where I stand. > > > > Where you stand? I’m not certain what you mean and was not trying to say > > something about you personally. > > I didnt take it personal, That is not what I meant. To me SELinux is bigger > then any single policy be it refpolicy, sepolicy, or dssp > The perfect tool would support any policy (setools goes a long way there). > From your comments I sensed that you might not fully agree with that or that > you might not have the ambition for SPAN to be perfect. > What I am saying is that after your comment I no longer have any illusions > that SPAN will ever be perfect (or close to perfect) > > > > > I was not familiar with DSSP before (I’ve not done much with SELinux for a > > while), but Josh pointed it out to me. From looking at it very briefly and > > thinking through the assumptions in SPAN my guess is that it would take > > very few changes to make SPAN work with DSSP, even the source policy stuff > > (which, honestly, is just a very small part mainly useful for diffing > > constraints). > > > > And as a side note - it’s nice to see someone trying to write a policy from > > scratch in CIL. Do you have a “domain” attribute or at least a similar > > concept? > > Sure, but i cannot use "domain" for this because DSSP leverages namespaces. > The equivalent in DSSP is "subj.subj_type_attribute" > > So if the configuration file would have something like: > > # process_types = domain > > Then i would be happy because then i could edit it like: > > process_types = subj.subj_type_attribute > > > > > > I will not be able to leverage this solution to any significant extend, > > > and the notebook and its depenedencies are pretty expensive to have just > > > for something that only works to some extent. > > > > I’m curious what you mea
Re: Announcing SPAN: SELinux Policy Analysis Notebook
On Mon, May 08, 2017 at 04:09:16PM -0400, Karl MacMillan wrote: > > > On May 8, 2017, at 3:49 PM, Dominick Grift <dac.overr...@gmail.com> wrote: > > > > On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote: > >> > >>> > >> > >> I think it’s best to think of these as having three basic layers: > >> > >> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable > >> for any policy and make no assumptions about the presence of any types, > >> attributes, object classes, or permissions. So things like the rule > >> searching and information flow analysis fit into this group. This is a > >> large part of the value of SPAN. > >> > >> 2. Higher-level policy analysis methods - these are things like the > >> domain_types method and the domain / type summaries. These make some > >> minimal assumptions about attributes like domain. I’ll just mention that > >> these assumptions are very minimal and have been around for a _long_ time. > >> Domain long pre-dates the reference policy, for example. More than > >> attributes this layer is tied to the Linux object classes and permissions. > >> > >> 3. Example notebooks - the two example notebooks are just that - examples. > >> They probably provide a useful starting point, but as Josh points out, > >> should simply be modified for your specific use case. > >> > >> So the question, then, is should the second layer (the higher-level policy > >> analysis methods) be made configurable. Honestly I think it would be more > >> work than just creating your own versions for a policy that breaks the > >> assumptions. To me, that’s the great advantage of this versus other > >> analysis tools. It’s so simple to create quick tools that meet your needs. > >> And given that the vast majority of Linux and Android systems meet the > >> assumptions I think that this is a reasonable approach. > > > > I don't think it will work with android. Some of it maybe but not all of > > it. for example the source functionality appends "modules" to the search > > path. So i suspect that will break that functionality for Android. > > We’ve not tested it for Android policies so I’m sure there will be some > breakage. But I hope it will be fixed to work by us or someone soon. > > > Thank you for giving me your opinion. At least now I know where I stand. > > Where you stand? I’m not certain what you mean and was not trying to say > something about you personally. I didnt take it personal, That is not what I meant. To me SELinux is bigger then any single policy be it refpolicy, sepolicy, or dssp The perfect tool would support any policy (setools goes a long way there). From your comments I sensed that you might not fully agree with that or that you might not have the ambition for SPAN to be perfect. What I am saying is that after your comment I no longer have any illusions that SPAN will ever be perfect (or close to perfect) > > I was not familiar with DSSP before (I’ve not done much with SELinux for a > while), but Josh pointed it out to me. From looking at it very briefly and > thinking through the assumptions in SPAN my guess is that it would take very > few changes to make SPAN work with DSSP, even the source policy stuff (which, > honestly, is just a very small part mainly useful for diffing constraints). > > And as a side note - it’s nice to see someone trying to write a policy from > scratch in CIL. Do you have a “domain” attribute or at least a similar > concept? Sure, but i cannot use "domain" for this because DSSP leverages namespaces. The equivalent in DSSP is "subj.subj_type_attribute" So if the configuration file would have something like: # process_types = domain Then i would be happy because then i could edit it like: process_types = subj.subj_type_attribute > > > I will not be able to leverage this solution to any significant extend, and > > the notebook and its depenedencies are pretty expensive to have just for > > something that only works to some extent. > > I’m curious what you mean by “only works to some extent”. Any bug reports > would be welcome. Let me rephrase then: "not to the fullest extent" But you gave me the impression that not all bug reports would be "welcome" when you said: "the vast majority of Linux and Android systems meet the assumptions I think that this is a reasonable approach." > > And if you mean specifically in the context of DSSP, like I said I bet the > changes would be minimal. So if you are int
Re: Announcing SPAN: SELinux Policy Analysis Notebook
On Mon, May 08, 2017 at 03:36:21PM -0400, Karl MacMillan wrote:
>
> > On May 8, 2017, at 5:32 AM, Dominick Grift <dac.overr...@gmail.com> wrote:
> >
> > On Mon, May 08, 2017 at 10:55:55AM +0200, Dominick Grift wrote:
> >> On Sun, May 07, 2017 at 03:42:50PM -0400, Joshua Brindle wrote:
> >>> Dominick Grift wrote:
> >>>> On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the
> >>>>> Dominick Grift wrote:
> >>>>>
> >>>>>
> >>>>>> The idea is nice, unfortunately its inflexible and it has
> >>>>>> hard-references to reference policy all-over. It has potential but it
> >>>>>> is still rough.
> >>>>>>
> >>>>> Of course, it is an analysis of a refpolicy-based policy. If you want to
> >>>>> analyze a different policy (e.g., Android or home-rolled) you will have
> >>>>> to
> >>>>> change out all of the type sets, etc.
> >>>>>
> >>>>> You can't make a magic generic analysis script without knowing how key
> >>>>> parts
> >>>>> of the system work and what types are associated with those components.
> >>>>
> >>>> What do you mean? that for example that hard-coded array of "trusted"
> >>>> types. Is that not just redundant.
> >>>>
> >>>
> >>> you mean the example trusted types? I'm not sure I understand your
> >>> concern.
> >>>
> >>>> Can't i just create that array myself and use it to exlude rules with
> >>>> types in that array? That was one does not have to hard-code it.
> >>>>
> >>>
> >>> It is python, you can do anything you want. The example notebook is a
> >>> starting point, anyone doing an analysis would probably make major changes
> >>> for their analysis, which is the point. You modify the notebook to build a
> >>> usable analysis between the starting policy and the policy you are
> >>> analyzing.
> >>>
> >>> I've thought about trying this on an Android policy but haven't made it a
> >>> priority.
> >>>
> >>>> Also with regard to hardcoding the refpolicy file system
> >>>> (ps.load_policy_source). I mean if youre just going to `grep -r` then
> >>>> why do we have to assume anything there and hard code file suffixed,
> >>>> directory structures etc etc?
> >>>
> >>>
> >>
> >> ahh.. sorry. I just noticed that it can be overriden:
> >>
> >> p, ps, bp, bps = se.load_policies_from_config("policy_paths.config")
> >>
> >> so i suppose i should be able to add that file to the notebook dir and
> >> specify my own paths.
> >>
> >> although that still doesnt deal with any file suffixes? (.cil)
> >
> >
> > take for example:
> > https://github.com/QuarkSecurity/SPAN/blob/master/span/span.py#L331
> > <https://github.com/QuarkSecurity/SPAN/blob/master/span/span.py#L331>
> >
> > "domain" is a reference policy type attribute
> >
> > One should expand on the "policy_paths.config" concept and allow us, via
> > configuration files, to override all the variables (attributes, suffixes,
> > paths, identifiers, etc)
> >
> > So that the variables can we adjusted without the need to
> > reinstall/recompile a modified SPAN
> >
> > Or just rename to RPAN (reference policy analysis notebook)
>
> I think it’s best to think of these as having three basic layers:
>
> 1. Basic tools for SELinux policy analysis in Jupyter - these are usable for
> any policy and make no assumptions about the presence of any types,
> attributes, object classes, or permissions. So things like the rule searching
> and information flow analysis fit into this group. This is a large part of
> the value of SPAN.
>
> 2. Higher-level policy analysis methods - these are things like the
> domain_types method and the domain / type summaries. These make some minimal
> assumptions about attributes like domain. I’ll just mention that these
> assumptions are very minimal and have been around for a _long_ time. Domain
> long pre-dates the reference policy, for example. More than attributes this
> layer is tied to the Linux object classes and permissions.
>
> 3. Example notebooks - the two example notebooks are just that - examples.
> They probably p
Re: Announcing SPAN: SELinux Policy Analysis Notebook
On Mon, May 08, 2017 at 03:23:06PM -0400, Karl MacMillan wrote: > > > On May 7, 2017, at 5:39 AM, Dominick Grift <dac.overr...@gmail.com> wrote: > > > > On Sat, May 06, 2017 at 07:19:20PM +0200, Dominick Grift wrote: > >> On Sat, May 06, 2017 at 06:19:56PM +0200, Dominick Grift wrote: > >>> On Sat, May 06, 2017 at 04:03:58PM +0200, Dominick Grift wrote: > > [snip] > > >>>> > >>>> Nice! Unfornately i could not, which my limited capacity, get it to > >>>> work. Here is what i tried: > >>>> > >>>> Fedora 26 (alpha): > >>>> sudo dnf install setools setools-console libselinux-python3 pandoc which > >>>> git clone https://github.com/quarcksecurity/span && cd span && pip3 > >>>> install . --user > >>>> cd examples && jupyter-notebook > >>>> > >>>> As soon as i try to run any "cell" or do "restart kernel and run all > >>>> cells" it throws stack traces about "ModuleNotFoundError" (import span > >>>> as se" and "from sh import pandoc" > >>>> > >>>> All the stuff seems to be installed properly in > >>>> ~/.local/lib/python3.6/site-packages, and the stack traces do refer to > >>>> the proper paths suchs as for example: > >>>> "/home/joe/.local/lib/python3.6/site-packages/span/domain_summary_to_word.py > >>>> in ()" > >>> > >>> I dont know exactly what the issue is but after installing the following > >>> from the fedora repository i seem to have it working: > >>> > >>> python3-pypandoc > >>> python3-pandocfilters > >>> python3-sh > >>> > >>> So i suspect the "from sh import pandoc" was the issue because sh was not > >>> in the python_requirements.txt, but even after adding it there it still > >>> did not work > >> > > I updated python_requirements.txt to include sh - thanks for that. > > >> The idea is nice, unfortunately its inflexible and it has hard-references > >> to reference policy all-over. It has potential but it is still rough. > > > > > > Turns out that Fedora provides all the dependencies (some just have > > different names) > > > > I have created a Fedora SPAN.spec: > > > > https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec > > <https://github.com/DefenSec/selinux-rpm-spec/blob/master/SPAN.spec> > > > > > > Thanks for making the Fedora SPEC. > > I know it’s a topic of great debate, but there are some nice things about > just sticking with the Python tools for dependency management for upstream. > Mainly because it’s portable and helps get the latest versions (which is nice > for fast moving projects like Jupyter notebook and Pandas). Yes it is pretty cool (pip) and this event actually prompted me to make pip work in my environment. However for me in this case it is really not an option. Its nice for simple python modules but python programs such as notebook need permissions that i do not associate will login users shells, and i dont support confining applications installed to $HOME. notebook needs permissions like execmem, needs network connectivity and a few other things that i do not allow my user login shells. So I have to make this work system-wide and I wanted the benefit of being able to manage/keep track off what i install system-wide > > Karl > > > >> > >>> > >>>> > >>>> -- > >>>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > >>>> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > >>>> Dominick Grift > >>> > >>> > >>> > >>> -- > >>> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > >>> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > >>> Dominick Grift > >> > >> > >> > >> -- > >> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > >> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > >> Dominick Grift > > > > > > > > -- > > Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 > > https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 > > <https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02> > > Dominick Grift > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
Re: Announcing SPAN: SELinux Policy Analysis Notebook
On Mon, May 08, 2017 at 10:55:55AM +0200, Dominick Grift wrote:
> On Sun, May 07, 2017 at 03:42:50PM -0400, Joshua Brindle wrote:
> > Dominick Grift wrote:
> > > On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the
> > > > Dominick Grift wrote:
> > > >
> > > >
> > > > > The idea is nice, unfortunately its inflexible and it has
> > > > > hard-references to reference policy all-over. It has potential but it
> > > > > is still rough.
> > > > >
> > > > Of course, it is an analysis of a refpolicy-based policy. If you want to
> > > > analyze a different policy (e.g., Android or home-rolled) you will have
> > > > to
> > > > change out all of the type sets, etc.
> > > >
> > > > You can't make a magic generic analysis script without knowing how key
> > > > parts
> > > > of the system work and what types are associated with those components.
> > >
> > > What do you mean? that for example that hard-coded array of "trusted"
> > > types. Is that not just redundant.
> > >
> >
> > you mean the example trusted types? I'm not sure I understand your concern.
> >
> > > Can't i just create that array myself and use it to exlude rules with
> > > types in that array? That was one does not have to hard-code it.
> > >
> >
> > It is python, you can do anything you want. The example notebook is a
> > starting point, anyone doing an analysis would probably make major changes
> > for their analysis, which is the point. You modify the notebook to build a
> > usable analysis between the starting policy and the policy you are
> > analyzing.
> >
> > I've thought about trying this on an Android policy but haven't made it a
> > priority.
> >
> > > Also with regard to hardcoding the refpolicy file system
> > > (ps.load_policy_source). I mean if youre just going to `grep -r` then why
> > > do we have to assume anything there and hard code file suffixed,
> > > directory structures etc etc?
> >
> >
>
> ahh.. sorry. I just noticed that it can be overriden:
>
> p, ps, bp, bps = se.load_policies_from_config("policy_paths.config")
>
> so i suppose i should be able to add that file to the notebook dir and
> specify my own paths.
>
> although that still doesnt deal with any file suffixes? (.cil)
take for example:
https://github.com/QuarkSecurity/SPAN/blob/master/span/span.py#L331
"domain" is a reference policy type attribute
One should expand on the "policy_paths.config" concept and allow us, via
configuration files, to override all the variables (attributes, suffixes,
paths, identifiers, etc)
So that the variables can we adjusted without the need to reinstall/recompile a
modified SPAN
Or just rename to RPAN (reference policy analysis notebook)
>
> --
> Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
> https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
> Dominick Grift
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: Announcing SPAN: SELinux Policy Analysis Notebook
On Sun, May 07, 2017 at 03:42:50PM -0400, Joshua Brindle wrote:
> Dominick Grift wrote:
> > On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the
> > > Dominick Grift wrote:
> > >
> > >
> > > > The idea is nice, unfortunately its inflexible and it has
> > > > hard-references to reference policy all-over. It has potential but it
> > > > is still rough.
> > > >
> > > Of course, it is an analysis of a refpolicy-based policy. If you want to
> > > analyze a different policy (e.g., Android or home-rolled) you will have to
> > > change out all of the type sets, etc.
> > >
> > > You can't make a magic generic analysis script without knowing how key
> > > parts
> > > of the system work and what types are associated with those components.
> >
> > What do you mean? that for example that hard-coded array of "trusted"
> > types. Is that not just redundant.
> >
>
> you mean the example trusted types? I'm not sure I understand your concern.
>
> > Can't i just create that array myself and use it to exlude rules with types
> > in that array? That was one does not have to hard-code it.
> >
>
> It is python, you can do anything you want. The example notebook is a
> starting point, anyone doing an analysis would probably make major changes
> for their analysis, which is the point. You modify the notebook to build a
> usable analysis between the starting policy and the policy you are
> analyzing.
>
> I've thought about trying this on an Android policy but haven't made it a
> priority.
>
> > Also with regard to hardcoding the refpolicy file system
> > (ps.load_policy_source). I mean if youre just going to `grep -r` then why
> > do we have to assume anything there and hard code file suffixed, directory
> > structures etc etc?
>
>
ahh.. sorry. I just noticed that it can be overriden:
p, ps, bp, bps = se.load_policies_from_config("policy_paths.config")
so i suppose i should be able to add that file to the notebook dir and specify
my own paths.
although that still doesnt deal with any file suffixes? (.cil)
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02
Dominick Grift
signature.asc
Description: PGP signature
Re: Announcing SPAN: SELinux Policy Analysis Notebook
On Sun, May 07, 2017 at 03:42:50PM -0400, Joshua Brindle wrote: > Dominick Grift wrote: > > On Sun, May 07, 2017 at 11:22:00AM -0400, Joshua Brindle wrote:the > > > Dominick Grift wrote: > > > > > > > > > > The idea is nice, unfortunately its inflexible and it has > > > > hard-references to reference policy all-over. It has potential but it > > > > is still rough. > > > > > > > Of course, it is an analysis of a refpolicy-based policy. If you want to > > > analyze a different policy (e.g., Android or home-rolled) you will have to > > > change out all of the type sets, etc. > > > > > > You can't make a magic generic analysis script without knowing how key > > > parts > > > of the system work and what types are associated with those components. > > > > What do you mean? that for example that hard-coded array of "trusted" > > types. Is that not just redundant. > > > > you mean the example trusted types? I'm not sure I understand your concern. Yes my mistake, that array is just an example? Anyhow it distracted me. The array isnt so much an issue. The bigger issue is that i cannot easily override the ps.policy_config_source file suffixes and paths from the notebook (am i over looking this?) But yes, i think these issues will eventually be addressed automatically. It works pretty well for me now. > > > Can't i just create that array myself and use it to exlude rules with types > > in that array? That was one does not have to hard-code it. > > > > It is python, you can do anything you want. The example notebook > is a starting point, anyone doing an analysis would probably make > major changes for their analysis, which is the point. You modify > the notebook to build a usable analysis between the starting > policy and the policy you are analyzing. > > I've thought about trying this on an Android policy but haven't > made it a priority. > Python is not really my thing so i will have to get used to it and explore my options Its a cool module, has a few rough edges (but thats to be expected from v0.0.0) > > Also with regard to hardcoding the refpolicy file system > > (ps.load_policy_source). I mean if youre just going to `grep -r` then why > > do we have to assume anything there and hard code file suffixed, directory > > structures etc etc? > > -- Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02 https://sks-keyservers.net/pks/lookup?op=get=0x3B6C5F1D2C7B6B02 Dominick Grift signature.asc Description: PGP signature
