[refpolicy] Help with policy definition.

[guido@trentalancia.com (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