/dev/pts/0 vs /pts/0

Latest response

I just noticed that when I see sudo in /var/log/secure, the associated terminal is always "/dev/pts/0" but when it's su it is just "pts/0". Here are 2 examples:

 

Time: UTC

Server:

Message: >> <14>Apr 15 09:17:59 audispd: node=server1 type=CRED_ACQ msg=audit(1366010279.044:1584474): user pid=15118 uid=0 auid=15357 msg='PAM: setcred acct="oracle" : exe="/bin/su" (hostname=?, addr=?, terminal=pts/0 res=success)'

 

Time:

Server:

Message: >> <14>Apr 15 09:17:59 audispd: node=server1 type=CRED_ACQ msg=audit(1366010279.028:1584467): user pid=15118 uid=0 auid=15357 msg='PAM: setcred acct="root" : exe="/usr/bin/sudo" (hostname=server1, addr=, terminal=/dev/pts/0

Our Security team is very much concerned about this. Is it going to be security flaw? Please help me.

DM
Log in to join the conversation

Responses

rh Red Hat Guru 4540 points
2 May 2013 7:06 PM

su and sudo come from different source packages whose approach to audit logging is slightly different.

sudo calls the audit library directly: (from sudo-1.8.6p3/src/selinux.c):

     63 #ifdef HAVE_LINUX_AUDIT
     64 static int
     65 audit_role_change(const security_context_t old_context,
     66     const security_context_t new_context, const char *ttyn, int result)
     67 {
     68     int au_fd, rc = -1;
     69     char *message;
     70     debug_decl(audit_role_change, SUDO_DEBUG_SELINUX)
     71 
     72     au_fd = audit_open();
     73     if (au_fd == -1) {
     74         /* Kernel may not have audit support. */
     75         if (errno != EINVAL && errno != EPROTONOSUPPORT && errno != EAFNOSUPPORT
     76 )
     77             error(1, _("unable to open audit system"));
     78     } else {
     79  /* audit role change using the same format as newrole(1) */
     80     easprintf(&message, "newrole: old-context=%s new-context=%s",
     81      old_context, new_context);
     82  rc = audit_log_user_message(au_fd, AUDIT_USER_ROLE_CHANGE,
     83      message, NULL, NULL, ttyn, result);

Following the origins of and data flow around the "ttyn" argument, it can be seen that it is a full device name (/dev/pts/...) which isn't being stripped down.

su on the other hand comes from coreutils. coreutils leaves audit logging to the PAM library, providing it with a tty device name that has a leading "/dev/" stripped off from it: (from Linux-PAM-1.1.1/libpam/pam_audit.c):

    310   ttyn = ttyname(0);
    311   if (ttyn) {
    312     if (strncmp(ttyn, "/dev/", 5) == 0)
    313        tty_name = ttyn+5;
    314     else
    315        tty_name = ttyn;
    316     retval = pam_set_item(pamh, PAM_TTY, tty_name);
    317     PAM_BAIL_P;

I see no way in which this minor difference in approach could have security implications.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.