unconfined domain equals permissive?

[KaiGai Kohei]

Dan,

I could find the following policy at the recent rawhide policy.
(such as selinux-policy-3.6.31-2.fc12.src.rpm).

--------------------
interface(`unconfined_domain',`
        gen_require(`
                attribute unconfined_services;
        ')

        #               unconfined_domain_noaudit($1)
        permissive $1;

        tunable_policy(`allow_execheap',`
                auditallow $1 self:process execheap;
        ')
')
--------------------

Is it a workaround fix? Or, do you have a plan to change the definition
of unconfined domains at the F-12/rawhide?

The permissive domains are also allowed to bypass MLS/MCS rules, not only
TE rules, so it seems to me its impact is a bit unignorable, if it is not
a workaround.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@...>

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Daniel J Walsh]

On 09/11/2009 12:42 AM, KaiGai Kohei wrote:

> Dan,
>
> I could find the following policy at the recent rawhide policy.
> (such as selinux-policy-3.6.31-2.fc12.src.rpm).
>
> --------------------
> interface(`unconfined_domain',`
>         gen_require(`
>                 attribute unconfined_services;
>         ')
>
>         #               unconfined_domain_noaudit($1)
>         permissive $1;
>
>         tunable_policy(`allow_execheap',`
>                 auditallow $1 self:process execheap;
>         ')
> ')
> --------------------
>
> Is it a workaround fix? Or, do you have a plan to change the definition
> of unconfined domains at the F-12/rawhide?
>
> The permissive domains are also allowed to bypass MLS/MCS rules, not only
> TE rules, so it seems to me its impact is a bit unignorable, if it is not
> a workaround.
>
> Thanks,

No this is temporary to help me find bugs in policy.  I am encouraging people to remove the unconfined.pp policy package which takes away the unconfined_domain.  So I am just gathering avc's until we release Beta1.  I will probably change it back in about a week.

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Jon Mineiko]

Can someone call me at 630-519-3323. I'm having a issue with syslog-ng permissions too. There doesn't seem to be a policy for me to enable in selinux. So I need help creating one. I found some documentation online that suggests there should be. 

On Sep 11, 2009, at 7:21 AM, Daniel J Walsh wrote:

On 09/11/2009 12:42 AM, KaiGai Kohei wrote:

Dan,

I could find the following policy at the recent rawhide policy.

(such as selinux-policy-3.6.31-2.fc12.src.rpm).

--------------------

interface(`unconfined_domain',`

       gen_require(`

               attribute unconfined_services;

       ')

       #               unconfined_domain_noaudit($1)

       permissive $1;

       tunable_policy(`allow_execheap',`

               auditallow $1 self:process execheap;

       ')

')

--------------------

Is it a workaround fix? Or, do you have a plan to change the definition

of unconfined domains at the F-12/rawhide?

The permissive domains are also allowed to bypass MLS/MCS rules, not only

TE rules, so it seems to me its impact is a bit unignorable, if it is not

a workaround.

Thanks,

No this is temporary to help me find bugs in policy.  I am encouraging people to remove the unconfined.pp policy package which takes away the unconfined_domain.  So I am just gathering avc's until we release Beta1.  I will probably change it back in about a week.

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

Jon Mineiko

Row44 Inc.

jm@...

desk 630-519-3323

cell 708-321-0211

gtalk jm7000@...

------BEGIN PGP PUBLIC KEY BLOCK-----

Version: 9.9.1.287

mQENBEpLh1kBCADYsBo2yI2wpyuX/cXObnjMIv8OL1ea21ObpOHe9x2/LL1EYp7K

+mlFhV4HntZ5bBpu7zX/fk4eF5ZCYubmrJwHn7M61hqLeo7SYnqlNQfqiQcw3+Xp

fLKVfxQxxMMoSE3Wv4NRw267F1c4wcO1M7NgraFgem4OJWZDjwA3r4FkR4n6u9ia

VxgVjugNniavUPI7TV4m+48K3kiqax8VZfaOxL31HMB6vaFjNYfI6xwM3mvkT/MT

G3btkE6PfUvVW1tW32REHk4JT5GnM4Tf2YEmnVTWVvwXbtORIb84+ozqw3MWwb0g

0mUwOSHWtK7Ao3OlpMMnam+Q15s+NAK205nDABEBAAG0HUpPTiBNSU5FSUtPIDxq

bUBkYXRhdGVsZS5jb20+iQGHBBABAgBxBQJKS43OMBSAAAAAACAAB3ByZWZlcnJl

ZC1lbWFpbC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQcLCQgHAwIKAhkBGRhsZGFw

Oi8va2V5c2VydmVyLnBncC5jb20FGwMAAAADFgIBBR4BAAAABBUICQoACgkQ/AVQ

TqDllmu+fwgAsN2QYlyKkhtPlHuhvTA7+Zso5oWms0/ipij0wfj0oLrrifz2Ku6u

vauSat8H8BX1mVDRA7uT2cI/7umaQ8QGJWouTWokwAOgDGNdyLRpDI6ssI0i8MU9

Hv2+zKABtR7cdVsmgS3juTuyvAqxPrJ38AZEOxwY00dwwzPFlXFG8ybQ8rVzP1bD

jnk+ol6Di53v6vpJ44iJqt83LW0dYrhwQWtgbt/p+vT6XdK9S6z2HJy+Wuvdh88f

tBtxJ5p19gzSFZ71h4bOybbe4dXqZI+0U2RoMO2zYjV1zDugvpLQXCxqvYUSYwkR

m4JLG2YPnBTC7DYDR8Z8q4z55n/k2W8gCrQeSk9OIE1JTkVJS08gPGptNzAwMEBn

bWFpbC5jb20+iQGEBBABAgBuBQJKS43OMBSAAAAAACAAB3ByZWZlcnJlZC1lbWFp

bC1lbmNvZGluZ0BwZ3AuY29tcGdwbWltZQcLCQgHAwIKGRhsZGFwOi8va2V5c2Vy

dmVyLnBncC5jb20FGwMAAAADFgIBBR4BAAAABBUICQoACgkQ/AVQTqDllmsfZwgA

jpbpL5oI6TP7KC/ZmhwjWX+l6mtFVsD35l6tR/0K/Dpo1Xc2wbsPzuwkl0/3EdB8

m40L5nOt4qSWXE4nCT+18jhmvaV8fDSm6k13/iz3M7gnLySzEyF9VMpxhpIxiHzJ

gUhoOdj+RMsQQr3xxaobRN2PU9HeLJH+osFbQC3WrX0f+ha8speebe1zpNgoAzTZ

rmOpHmOlBXeaNq0WrTr1F0UOIx45tvoYe1TYXvZMgw2hTimiaVoeY4dvqma0dxFS

7NJNl0F+q8b0cIKtdSyFwzh2I0fJFatyNqZSjeUKaq9uz2WCIpYn0jTseFVsF3E8

1Rp9GTb0kddKJyvY8XSHELQaSk9OIE1JTkVJS08gPGptQHJvdzQ0LmNvbT6JAYQE

EAECAG4FAkpLjc4wFIAAAAAAIAAHcHJlZmVycmVkLWVtYWlsLWVuY29kaW5nQHBn

cC5jb21wZ3BtaW1lBwsJCAcDAgoZGGxkYXA6Ly9rZXlzZXJ2ZXIucGdwLmNvbQUb

AwAAAAMWAgEFHgEAAAAEFQgJCgAKCRD8BVBOoOWWa0yyCACmfj2KcTB+YMEoiNhT

Xp4iXBVtxzppxmpercI3NFfx4rS+33Iy/4BPEYcdQqrr1xgVCXzv/BRmwwb41PPZ

6+tstMrS8APnqsW0RIxH3gYvXMu2k9oF9aNqc04vA7wJ4hnGtONyGDl2H3vGEm+Q

qhPY6cCaPk2085hQq6pNou9XWDfun0tYhh0BhFxLpbgLAWm9EdSH0WxjfevAKIDs

dixZutxscEnABmOoNkxBgOmCcewOKTvGhFdj+bVV/VelUSfyZryKiP44hzTntRKI

jEmHA6aCDMPxicoQZFsz+KqgjYWslSwOdtd0uPe4g8gfkVoFGA17NWuWVONIVrFK

H5ystCBKT04gTUlORUlLTyA8am1pbmVpa29Acm93NDQuY29tPokBhAQQAQIAbgUC

SkuNzjAUgAAAAAAgAAdwcmVmZXJyZWQtZW1haWwtZW5jb2RpbmdAcGdwLmNvbXBn

cG1pbWUHCwkIBwMCChkYbGRhcDovL2tleXNlcnZlci5wZ3AuY29tBRsDAAAAAxYC

AQUeAQAAAAQVCAkKAAoJEPwFUE6g5ZZrmpEIAItF2XKLitkRdySD+l4qMPiTiGLe

jLovMZV5zLi5zTYAdzlyE9s3fVNEH6/sDbj5NQM6AI3YU4t0+7p90I4TWUDFJfRb

W/Rak/vaYWsSJCbeqSn1Q5hht0ffIXmzvmS1VXraTQ2Z3mSol8j/e51DkUtcVdae

CxRpT0it5pOCkz6i4y96NM8ubD7wambmBCjr3lsX5vsev8LMDfgfBJFVs8KIUEyU

SuPbKb4YT3ZV2uhbVCyLr1UJsvRTGa5fFJ6RZW2MzFmnAme+wyVPwFrqZu41OR7t

QdmigZ3im24J61Ut35ak7FEhSN/1nCbHJisB7gb5oPr/sXXmMcha57wWN065AQ0E

SkuHWgEIAMrJn6/XdkOgQBq2Sxmmn56YTOvf6iXGK4DJEqL5SIPGi9Q/JnWkyxgp

I2YwDaZkuvMctM1MpzMy9XnEEfIIMgbdCsA0OF7lzMgpU6DKVcZeaDnjiEve84Be

GNysMxBsGfkmPF+QJKHjUkCsJtl2sawoLWFd4rTOYtdYtzDd1WXKSJNAdeWrlL1e

z1GY7xAqCfHJpW85dqJfC+1gg6BDYOGwyYGo0EimPcBhBI2MRq0bDhmDlp4TqW2p

2BcgbogM+CsUR4vstirdkZdgFaOm04rI+BHERnEEzKyARlFixbQtUabwxFhO7zYx

WqLwlydiAvanq1E4ekrBEIIUW0RYEtMAEQEAAYkCQQQYAQIBKwUCSkuHWwUbDAAA

AMBdIAQZAQgABgUCSkuHWgAKCRCbWL+CsfdQBrQJB/40dKjEWAuoGap5UlHMmA2B

HG8k+yC8qmmO9MGD/mCBegBJOkILyjA+7JijwenKPAHEL6nDa5OEk+/jDxAWdku3

yuRdz4MOnb8tS0qorBLju4tddr4KcP1GlLjZdBlaK78si5QQRrx8/9fsF3LhRRK1

XrJ6aALld0SQxVKXUWrz3/xxVAPk0YyvV/U+Mh7Zwjf3R9mLp9XtFMmuokvWKNAD

VAaS5BRFtqRcQjN7tcrVwafRsqpQiP+pp1m8hKg4OoYQHKDKNUzSlVCpoh9Gy7Nx

9jXpwHl1P/niKGt5KChat5q0t8quQbnKJwj/XAi08PxafnZTN8hn+Rbd2Wc/R4E9

AAoJEPwFUE6g5ZZrueIH/R+U/XVhxaa0bQ+SMd8xrw78ejquzyak2dHfHqgSEv1T

5ormbkLVNNzlYhhhn7JwL7eEU5wKdBW2AFmm6sF5TvkydnFDRHWz8NTSXeY59ua1

7xlulHIAAwJN78Bt1z1l+SXX4x6Z6X6CbFC00/LXoHqSCUixyak6L6jkmb2P5hvl

z8pupWmnOarliIBN1FId06JSMs8TiqaGRIlDs4EAuW4zIRZke0zJBGP/P1OIEJcT

77s0QPqDVpvEK+yX7NUr/kAc3TUNj88Oov5s/eP5EPmiINctin8ISn43i8x/mPRl

GDDXUTsabwhPNYCNk3PsPvfs79Akl0Bs9yCslDayj5E=

=PDPT

-----END PGP PUBLIC KEY BLOCK-----

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Anamitra Dutta Majumdar (anmajumd)]

 
We need a way to unconfine the root user with the strict policy being
loaded in RHEL5.4. Currently with the strict policy the security context
for root user is root:staff_r:staff_t.
Is there a way to do so.


Thanks
Anamitra & Radha



--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Anamitra Dutta Majumdar (anmajumd)]

 Hi Dan,

 Thanks for you response.
 
 We attempted to set ssh_sysadm_login to 1 in the booleans file for our
strict policy. We also did an setsebool -P to turn on ssh_sysadm_login.
We also modified the security context of root user to
 root:sysadm_r:sysadm_t. We see a couple of issues now

 1. The value for ssh_sysadm_login is not persistent across reboots
 2. Even when the ssh_sysadm_login is turned on we cannot login as root
user

The sealert messaged seem to indicate the following . What else do we
need to do to get it working?

[root@vos-cm98 ~]# sealert -l e7c8894d-a508-430a-a594-da2a693e585f

Summary:

SELinux is preventing sshd (sshd_t) "execute" to /lib/libdl-2.5.so
(lib_t).

Detailed Description:

SELinux denied access requested by sshd. It is not expected that this
access is
required by sshd and this access may signal an intrusion attempt. It is
also
possible that the specific version or configuration of the application
is
causing it to require additional access.

Allowing Access:

Sometimes labeling problems can cause SELinux denials. You could try to
restore
the default system file context for /lib/libdl-2.5.so,

restorecon -v '/lib/libdl-2.5.so'

If this does not work, there is currently no automatic way to allow this
access.
Instead, you can generate a local policy module to allow this access -
see FAQ
(http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can
disable
SELinux protection altogether. Disabling SELinux protection is not
recommended.
Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
against this package.

Additional Information:

Source Context                system_u:system_r:sshd_t:s0
Target Context                system_u:object_r:lib_t:s0
Target Objects                /lib/libdl-2.5.so [ file ]
Source                        sshd
Source Path                   /usr/sbin/sshd
Port                          <Unknown>
Host                          vos-cm98.cisco.com
Source RPM Packages           openssh-server-4.3p2-36.el5
Target RPM Packages           glibc-2.5-42
Policy RPM                    selinux-policy-2.4.6-255.el5
Selinux Enabled               True
Policy Type                   strict
MLS Enabled                   False
Enforcing Mode                Enforcing
Plugin Name                   catchall_file
Host Name                     vos-cm98.cisco.com
Platform                      Linux vos-cm98.cisco.com 2.6.18-160.el5PAE
#1 SMP
                              Mon Jul 27 17:45:11 EDT 2009 i686 i686
Alert Count                   3
First Seen                    Tue Sep 15 16:02:26 2009
Last Seen                     Tue Sep 15 17:51:19 2009
Local ID                      e7c8894d-a508-430a-a594-da2a693e585f
Line Numbers                  

Raw Audit Messages            

host=vos-cm98.cisco.com type=AVC msg=audit(1253062279.960:406): avc:
denied  { execute } for  pid=4261 comm="sshd" path="/lib/libdl-2.5.so"
dev=dm-0 ino=51413920 scontext=system_u:system_r:sshd_t
tcontext=system_u:object_r:lib_t tclass=file

host=vos-cm98.cisco.com type=SYSCALL msg=audit(1253062279.960:406):
arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=3078 a2=5 a3=802
items=0 ppid=3119 pid=4261 auid=4294967295 uid=0 gid=0 euid=0 suid=0
fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t key=(null)

   
Thanks
Anamitra


-----Original Message-----
From: Daniel J Walsh [mailto:dwalsh@...]
Sent: Friday, September 11, 2009 1:49 PM
To: Anamitra Dutta Majumdar (anmajumd)
Subject: Re: Unconfining root user in strict policy mode

On 09/11/2009 04:34 PM, Anamitra Dutta Majumdar (anmajumd) wrote:

>  
> We need a way to unconfine the root user with the strict policy being
> loaded in RHEL5.4. Currently with the strict policy the security
> context for root user is root:staff_r:staff_t.
> Is there a way to do so.
>
>
> Thanks
> Anamitra & Radha
>
>
>
> --
> fedora-selinux-list mailing list
> fedora-selinux-list@...
> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>
>

There is no unconfined_t for Strict policy but you can set the root
account to login as sysadm_t which is very close

You have to turn on the ssh_sysadm_login if you want to login via ssh as
sysadm_t

And I think remove staff_r from root account will set it up to login as
sysadm_r

something like

# semanage user -m -R"sysadm_r system_r" root

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list

[Daniel J Walsh]

On 09/15/2009 08:58 PM, Anamitra Dutta Majumdar (anmajumd) wrote:

>
>  Hi Dan,
>
>  Thanks for you response.
>  
>  We attempted to set ssh_sysadm_login to 1 in the booleans file for our
> strict policy. We also did an setsebool -P to turn on ssh_sysadm_login.
> We also modified the security context of root user to
>  root:sysadm_r:sysadm_t. We see a couple of issues now
>
>  1. The value for ssh_sysadm_login is not persistent across reboots

setsebool -P should persist

>From the looks of it, you never relabeled when you switched to the strict policy.

touch /.autorelabel
reboot
Make sure you boot in permissive mode (Kernel option "enforcing=0")

>  2. Even when the ssh_sysadm_login is turned on we cannot login as root
> user
>
> The sealert messaged seem to indicate the following . What else do we
> need to do to get it working?
>
> [root@vos-cm98 ~]# sealert -l e7c8894d-a508-430a-a594-da2a693e585f
>
> Summary:
>
> SELinux is preventing sshd (sshd_t) "execute" to /lib/libdl-2.5.so
> (lib_t).
>
> Detailed Description:
>
> SELinux denied access requested by sshd. It is not expected that this
> access is
> required by sshd and this access may signal an intrusion attempt. It is
> also
> possible that the specific version or configuration of the application
> is
> causing it to require additional access.
>
> Allowing Access:
>
> Sometimes labeling problems can cause SELinux denials. You could try to
> restore
> the default system file context for /lib/libdl-2.5.so,
>
> restorecon -v '/lib/libdl-2.5.so'
>
> If this does not work, there is currently no automatic way to allow this
> access.
> Instead, you can generate a local policy module to allow this access -
> see FAQ
> (http://fedora.redhat.com/docs/selinux-faq-fc5/#id2961385) Or you can
> disable
> SELinux protection altogether. Disabling SELinux protection is not
> recommended.
> Please file a bug report
> (http://bugzilla.redhat.com/bugzilla/enter_bug.cgi)
> against this package.
>
> Additional Information:
>
> Source Context                system_u:system_r:sshd_t:s0
> Target Context                system_u:object_r:lib_t:s0
> Target Objects                /lib/libdl-2.5.so [ file ]
> Source                        sshd
> Source Path                   /usr/sbin/sshd
> Port                          <Unknown>
> Host                          vos-cm98.cisco.com
> Source RPM Packages           openssh-server-4.3p2-36.el5
> Target RPM Packages           glibc-2.5-42
> Policy RPM                    selinux-policy-2.4.6-255.el5
> Selinux Enabled               True
> Policy Type                   strict
> MLS Enabled                   False
> Enforcing Mode                Enforcing
> Plugin Name                   catchall_file
> Host Name                     vos-cm98.cisco.com
> Platform                      Linux vos-cm98.cisco.com 2.6.18-160.el5PAE
> #1 SMP
>                               Mon Jul 27 17:45:11 EDT 2009 i686 i686
> Alert Count                   3
> First Seen                    Tue Sep 15 16:02:26 2009
> Last Seen                     Tue Sep 15 17:51:19 2009
> Local ID                      e7c8894d-a508-430a-a594-da2a693e585f
> Line Numbers                  
>
> Raw Audit Messages            
>
> host=vos-cm98.cisco.com type=AVC msg=audit(1253062279.960:406): avc:
> denied  { execute } for  pid=4261 comm="sshd" path="/lib/libdl-2.5.so"
> dev=dm-0 ino=51413920 scontext=system_u:system_r:sshd_t
> tcontext=system_u:object_r:lib_t tclass=file
>
> host=vos-cm98.cisco.com type=SYSCALL msg=audit(1253062279.960:406):
> arch=40000003 syscall=192 success=no exit=-13 a0=0 a1=3078 a2=5 a3=802
> items=0 ppid=3119 pid=4261 auid=4294967295 uid=0 gid=0 euid=0 suid=0
> fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="sshd"
> exe="/usr/sbin/sshd" subj=system_u:system_r:sshd_t key=(null)
>
>    
> Thanks
> Anamitra
>
>
> -----Original Message-----
> From: Daniel J Walsh [mailto:dwalsh@...]
> Sent: Friday, September 11, 2009 1:49 PM
> To: Anamitra Dutta Majumdar (anmajumd)
> Subject: Re: Unconfining root user in strict policy mode
>
> On 09/11/2009 04:34 PM, Anamitra Dutta Majumdar (anmajumd) wrote:
>>  
>> We need a way to unconfine the root user with the strict policy being
>> loaded in RHEL5.4. Currently with the strict policy the security
>> context for root user is root:staff_r:staff_t.
>> Is there a way to do so.
>>
>>
>> Thanks
>> Anamitra & Radha
>>
>>
>>
>> --
>> fedora-selinux-list mailing list
>> fedora-selinux-list@...
>> https://www.redhat.com/mailman/listinfo/fedora-selinux-list
>>
>>
> There is no unconfined_t for Strict policy but you can set the root
> account to login as sysadm_t which is very close
>
> You have to turn on the ssh_sysadm_login if you want to login via ssh as
> sysadm_t
>
> And I think remove staff_r from root account will set it up to login as
> sysadm_r
>
> something like
>
> # semanage user -m -R"sysadm_r system_r" root

--
fedora-selinux-list mailing list
fedora-selinux-list@...
https://www.redhat.com/mailman/listinfo/fedora-selinux-list