[refpolicy] Help with policy definition.

[refpolicy] Help with policy definition.

[Sam Gandhi]

I am writing a policy for embedded device that I am working with. When
I am in permissive mode I can login to my console located on
/dev/ttymxc1.

which generate AVC message

user.notice kernel: type=1400 audit(165.890:8): avc:  denied  {
relabelto } for  pid=605 comm="login" name="ttymxc1" dev=tmpfs
ino=1475 scontext=system_u:system_r:kernel_t
tcontext=user_u:object_r:tty_device_t tclass=chr_file

which audit2allow says should translate to :

     allow kernel_t tty_device_t:chr_file relabelto;

Even if with above allow rule when in enforcing mode I am not able to
login to my serial console and I get message on the console.

login: chsid(/dev/ttymxc1, user_u:object_r:tty_device_t) failed:

/dev/ttymxc1 in my case has label of  user_u:object_r:tty_device_t

What am I missing in my configuration or any hints on how I should go
about debugging this issue/

/Sam

[refpolicy] Help with policy definition.

[Guido Trentalancia]

Hi Sam !

On Mon, 2011-06-06 at 16:26 -0700, Sam Gandhi wrote:
> I am writing a policy for embedded device that I am working with. When
> I am in permissive mode I can login to my console located on
> /dev/ttymxc1.
> 
> which generate AVC message
> 
> user.notice kernel: type=1400 audit(165.890:8): avc:  denied  {
> relabelto } for  pid=605 comm="login" name="ttymxc1" dev=tmpfs
> ino=1475 scontext=system_u:system_r:kernel_t
> tcontext=user_u:object_r:tty_device_t tclass=chr_file
> 
> which audit2allow says should translate to :
> 
>      allow kernel_t tty_device_t:chr_file relabelto;
> 
> Even if with above allow rule when in enforcing mode I am not able to
> login to my serial console and I get message on the console.

Have you tried to check for rules that are "dontaudit"'ed (semodule -DB
and then revert back using semodule -B once finished analysing) ?

> login: chsid(/dev/ttymxc1, user_u:object_r:tty_device_t) failed:

Can you do some sort of tracing of the system calls and signals close to
the failure point ?

There is something missing after "failed:" (the reason for failure) that
a human can hardly figure out...

And you are not using login from util-linux-ng, are you ?

And the policy, you didn't say much, is it plain refpolicy from git or
release ?

> /dev/ttymxc1 in my case has label of  user_u:object_r:tty_device_t
> 
> What am I missing in my configuration or any hints on how I should go
> about debugging this issue/

> /Sam

Guido

[refpolicy] Help with policy definition.

[Sam Gandhi]

On Mon, Jun 6, 2011 at 8:52 PM, Guido Trentalancia
<guido@trentalancia.com> wrote:
> Hi Sam !
>
> On Mon, 2011-06-06 at 16:26 -0700, Sam Gandhi wrote:
>> I am writing a policy for embedded device that I am working with. When
>> I am in permissive mode I can login to my console located on
>> /dev/ttymxc1.
>>
>> which generate AVC message
>>
>> user.notice kernel: type=1400 audit(165.890:8): avc: ?denied ?{
>> relabelto } for ?pid=605 comm="login" name="ttymxc1" dev=tmpfs
>> ino=1475 scontext=system_u:system_r:kernel_t
>> tcontext=user_u:object_r:tty_device_t tclass=chr_file
>>
>> which audit2allow says should translate to :
>>
>> ? ? ?allow kernel_t tty_device_t:chr_file relabelto;
>>
>> Even if with above allow rule when in enforcing mode I am not able to
>> login to my serial console and I get message on the console.
>
> Have you tried to check for rules that are "dontaudit"'ed (semodule -DB
> and then revert back using semodule -B once finished analysing) ?

I am working with a "monolithic" policy and not doing modules.

>
>> login: chsid(/dev/ttymxc1, user_u:object_r:tty_device_t) failed:
>
> Can you do some sort of tracing of the system calls and signals close to
> the failure point ?

The complete message is:
login: chsid(/dev/ttymxc1, user_u:object_r:tty_device_t) failed:
Permission denied

>
> There is something missing after "failed:" (the reason for failure) that
> a human can hardly figure out...
>
> And you are not using login from util-linux-ng, are you ?

I am using login program from the busybox.

>
> And the policy, you didn't say much, is it plain refpolicy from git or
> release ?
>
I am really not using conventional "refpolicy" from tresys, hope its
still okay to post quesitons about policy definition yto this mailing
list. I am using small policy that I found in openmoko project
http://code.google.com/p/selinux-openmoko/  and adding rules specific
to our daemons.

One thing, probably a bigger thing I left out was, this issue happens
only when my board is booted via NFS. I am able to login on console
when my board boots from flash file-system that support XATTR
labelling.

As per the suggestion I am running login as strace login and below is
snap of the output I see.
This is generated by ssh-ing into board and then running 'strace
login'.  I am running ssh in permissive mode i.e. using directive
"permissive sshd_t" in my policy.

I will continue my experiments but if you folks see something obvious
would appreciate the help!

read(4, "SELINUX=enforcing\nSELINUXTYPE=gr"..., 4096) = 38
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x40022000, 4096)                = 0
gettid()                                = 925
open("/proc/self/task/925/attr/current", O_RDONLY|O_LARGEFILE) = 4
read(4, "system_u:system_r:kernel_t\0", 4095) = 27
close(4)                                = 0
open("/selinux/user", O_RDWR|O_LARGEFILE) = 4
write(4, "system_u:system_r:kernel_t root", 31) = -1 EINVAL (Invalid argument)
close(4)                                = 0
open("/selinux/user", O_RDWR|O_LARGEFILE) = 4
write(4, "system_u:system_r:kernel_t user_"..., 33) = 33
read(4, "3\0user_u:system_r:insmod_t\0user_"..., 4095) = 75
close(4)                                = 0
open("/etc/selinux/mypolicy/contexts/users/user_u",
O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
open("/etc/selinux/mypolicy/contexts/default_contexts",
O_RDONLY|O_LARGEFILE) = 4
fstat64(4, {st_mode=S_IFREG|0644, st_size=253, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x40022000
read(4, "system_r:unconfined_t\tsystem_r:u"..., 4096) = 253
read(4, "", 4096)                       = 0
close(4)                                = 0
munmap(0x40022000, 4096)                = 0
getxattr("/dev/pts/3", "security.selinux",
"system_u:object_r:devpts_t", 255) = 27
open("/selinux/relabel", O_RDWR|O_LARGEFILE) = 4
write(4, "user_u:system_r:insmod_t system_"..., 54) = 54
read(4, "user_u:object_r:devpts_t\0", 4095) = 25
close(4)                                = 0
setxattr("/dev/pts/3", "security.selinux", "user_u:object_r:devpts_t",
25, 0) = -1 EACCES (Permission denied)
write(2, "login: chsid(/dev/pts/3, user_u:"..., 77login:
chsid(/dev/pts/3, user_u:object_r:devpts_t) failed: Permission denied
) = 77
exit_group(1)                           = ?


Regards,
-Sam

[refpolicy] Help with policy definition.

[Guido Trentalancia]

On Tue, 2011-06-07 at 08:30 -0700, Sam Gandhi wrote:
> On Mon, Jun 6, 2011 at 8:52 PM, Guido Trentalancia
> <guido@trentalancia.com> wrote:
> > Hi Sam !
> >
> > On Mon, 2011-06-06 at 16:26 -0700, Sam Gandhi wrote:
> >> I am writing a policy for embedded device that I am working with. When
> >> I am in permissive mode I can login to my console located on
> >> /dev/ttymxc1.
> >>
> >> which generate AVC message
> >>
> >> user.notice kernel: type=1400 audit(165.890:8): avc:  denied  {
> >> relabelto } for  pid=605 comm="login" name="ttymxc1" dev=tmpfs
> >> ino=1475 scontext=system_u:system_r:kernel_t
> >> tcontext=user_u:object_r:tty_device_t tclass=chr_file
> >>
> >> which audit2allow says should translate to :
> >>
> >>      allow kernel_t tty_device_t:chr_file relabelto;
> >>
> >> Even if with above allow rule when in enforcing mode I am not able to
> >> login to my serial console and I get message on the console.
> >
> > Have you tried to check for rules that are "dontaudit"'ed (semodule -DB
> > and then revert back using semodule -B once finished analysing) ?
> 
> I am working with a "monolithic" policy and not doing modules.
> 
> >
> >> login: chsid(/dev/ttymxc1, user_u:object_r:tty_device_t) failed:
> >
> > Can you do some sort of tracing of the system calls and signals close to
> > the failure point ?
> 
> The complete message is:
> login: chsid(/dev/ttymxc1, user_u:object_r:tty_device_t) failed:
> Permission denied
> 
> >
> > There is something missing after "failed:" (the reason for failure) that
> > a human can hardly figure out...
> >
> > And you are not using login from util-linux-ng, are you ?
> 
> I am using login program from the busybox.
> 
> >
> > And the policy, you didn't say much, is it plain refpolicy from git or
> > release ?
> >
> I am really not using conventional "refpolicy" from tresys, hope its
> still okay to post quesitons about policy definition yto this mailing
> list. I am using small policy that I found in openmoko project
> http://code.google.com/p/selinux-openmoko/  and adding rules specific
> to our daemons.
> 
> One thing, probably a bigger thing I left out was, this issue happens
> only when my board is booted via NFS. I am able to login on console
> when my board boots from flash file-system that support XATTR
> labelling.
> 
> As per the suggestion I am running login as strace login and below is
> snap of the output I see.
> This is generated by ssh-ing into board and then running 'strace
> login'.  I am running ssh in permissive mode i.e. using directive
> "permissive sshd_t" in my policy.

The limit of this approach, I suppose, is that by running it from ssh,
you might actually end up running it from another context rather than
the intended one (inficiated).

So the risk would be that the result is not relevant anymore as it won't
apply to the real case (of login running from the intended context).

But at least you can get more insight on what login was trying to do (as
apparently it breaks at the same point)...

> I will continue my experiments but if you folks see something obvious
> would appreciate the help!
> 
> read(4, "SELINUX=enforcing\nSELINUXTYPE=gr"..., 4096) = 38
> read(4, "", 4096)                       = 0
> close(4)                                = 0
> munmap(0x40022000, 4096)                = 0
> gettid()                                = 925
> open("/proc/self/task/925/attr/current", O_RDONLY|O_LARGEFILE) = 4
> read(4, "system_u:system_r:kernel_t\0", 4095) = 27
> close(4)                                = 0
> open("/selinux/user", O_RDWR|O_LARGEFILE) = 4
> write(4, "system_u:system_r:kernel_t root", 31) = -1 EINVAL (Invalid argument)
> close(4)                                = 0
> open("/selinux/user", O_RDWR|O_LARGEFILE) = 4
> write(4, "system_u:system_r:kernel_t user_"..., 33) = 33
> read(4, "3\0user_u:system_r:insmod_t\0user_"..., 4095) = 75
> close(4)                                = 0
> open("/etc/selinux/mypolicy/contexts/users/user_u",
> O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory)
> open("/etc/selinux/mypolicy/contexts/default_contexts",
> O_RDONLY|O_LARGEFILE) = 4
> fstat64(4, {st_mode=S_IFREG|0644, st_size=253, ...}) = 0
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
> 0) = 0x40022000
> read(4, "system_r:unconfined_t\tsystem_r:u"..., 4096) = 253
> read(4, "", 4096)                       = 0
> close(4)                                = 0
> munmap(0x40022000, 4096)                = 0
> getxattr("/dev/pts/3", "security.selinux",
> "system_u:object_r:devpts_t", 255) = 27
> open("/selinux/relabel", O_RDWR|O_LARGEFILE) = 4
> write(4, "user_u:system_r:insmod_t system_"..., 54) = 54
> read(4, "user_u:object_r:devpts_t\0", 4095) = 25
> close(4)                                = 0
> setxattr("/dev/pts/3", "security.selinux", "user_u:object_r:devpts_t",
> 25, 0) = -1 EACCES (Permission denied)
> write(2, "login: chsid(/dev/pts/3, user_u:"..., 77login:
> chsid(/dev/pts/3, user_u:object_r:devpts_t) failed: Permission denied
> ) = 77
> exit_group(1)                           = ?

What happens if you follow Christopher's advice of fixing the kernel_t
context in the first place, as it is the wrong context anyway and that
might probably be the definitive solution (although in some way I am
still missing the point of how kernel_t could be more restrictive than
anything else) ?

If that doesn't help, at least you know have more details about the
failed operation at the bottom of strace (and you've fixed something
which is definitely wrong and unsafe anyway).

> Regards,
> -Sam

Regards,

Guido

[refpolicy] Help with policy definition.

[Christopher J. PeBenito]

On 06/06/11 19:26, Sam Gandhi wrote:
> I am writing a policy for embedded device that I am working with. When
> I am in permissive mode I can login to my console located on
> /dev/ttymxc1.
> 
> which generate AVC message
> 
> user.notice kernel: type=1400 audit(165.890:8): avc:  denied  {
> relabelto } for  pid=605 comm="login" name="ttymxc1" dev=tmpfs
> ino=1475 scontext=system_u:system_r:kernel_t
> tcontext=user_u:object_r:tty_device_t tclass=chr_file

Looks like your login program is running in the wrong context.  It
should be local_login_t, not kernel_t.  Check the label on your init
program (eg /sbin/init) which should be init_exec_t.


> which audit2allow says should translate to :
> 
>      allow kernel_t tty_device_t:chr_file relabelto;
> 
> Even if with above allow rule when in enforcing mode I am not able to
> login to my serial console and I get message on the console.
> 
> login: chsid(/dev/ttymxc1, user_u:object_r:tty_device_t) failed:
> 
> /dev/ttymxc1 in my case has label of  user_u:object_r:tty_device_t
> 
> What am I missing in my configuration or any hints on how I should go
> about debugging this issue/


-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

[refpolicy] Help with policy definition.

[Guido Trentalancia]

On Tue, 2011-06-07 at 08:03 -0400, Christopher J. PeBenito wrote:
> On 06/06/11 19:26, Sam Gandhi wrote:
> > I am writing a policy for embedded device that I am working with. When
> > I am in permissive mode I can login to my console located on
> > /dev/ttymxc1.
> > 
> > which generate AVC message
> > 
> > user.notice kernel: type=1400 audit(165.890:8): avc:  denied  {
> > relabelto } for  pid=605 comm="login" name="ttymxc1" dev=tmpfs
> > ino=1475 scontext=system_u:system_r:kernel_t
> > tcontext=user_u:object_r:tty_device_t tclass=chr_file
> 
> Looks like your login program is running in the wrong context.  It
> should be local_login_t, not kernel_t.  Check the label on your init
> program (eg /sbin/init) which should be init_exec_t.

Shouldn't kernel_t be less restrictive than local_login_t (let alone the
fact that as you noted, it's wrong) ?

> > which audit2allow says should translate to :
> > 
> >      allow kernel_t tty_device_t:chr_file relabelto;
> > 
> > Even if with above allow rule when in enforcing mode I am not able to
> > login to my serial console and I get message on the console.
> > 
> > login: chsid(/dev/ttymxc1, user_u:object_r:tty_device_t) failed:
> > 
> > /dev/ttymxc1 in my case has label of  user_u:object_r:tty_device_t
> > 
> > What am I missing in my configuration or any hints on how I should go
> > about debugging this issue/
> 
> 

[refpolicy] Help with policy definition.

[Christopher J. PeBenito]

On 06/07/11 15:11, Guido Trentalancia wrote:
> On Tue, 2011-06-07 at 08:03 -0400, Christopher J. PeBenito wrote:
>> On 06/06/11 19:26, Sam Gandhi wrote:
>>> I am writing a policy for embedded device that I am working with. When
>>> I am in permissive mode I can login to my console located on
>>> /dev/ttymxc1.
>>>
>>> which generate AVC message
>>>
>>> user.notice kernel: type=1400 audit(165.890:8): avc:  denied  {
>>> relabelto } for  pid=605 comm="login" name="ttymxc1" dev=tmpfs
>>> ino=1475 scontext=system_u:system_r:kernel_t
>>> tcontext=user_u:object_r:tty_device_t tclass=chr_file
>>
>> Looks like your login program is running in the wrong context.  It
>> should be local_login_t, not kernel_t.  Check the label on your init
>> program (eg /sbin/init) which should be init_exec_t.
> 
> Shouldn't kernel_t be less restrictive than local_login_t (let alone the
> fact that as you noted, it's wrong) ?

Unless kernel_t is unconfined, local login is actually less restrictive.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com