Re: [PATCH] audit: handle loginuid through proc
* Albert Cahalan ([EMAIL PROTECTED]) wrote: > On Thu, 2005-02-24 at 22:49 -0800, Chris Wright wrote: > > * Albert Cahalan ([EMAIL PROTECTED]) wrote: > > > > Assuming you'd like ps to print the LUID, how about > > > putting it with all the others? There are "Uid:" > > > lines in the /proc/*/status files. > > > > It's also set (written) via /proc, so it should probably stay separate. > > Gross. Please rip this out before it hits the streets. > (it's an interface change that might need eternal support) It's already supported via the new pam_loginuid module. Also the loginuid is not a part of the task proper, rather the audit context. It's treated in a manner similar to security contexts which are handled via /proc interfaces. Having said that, I wouldn't be opposed to a patch that promotes it to compatible syscall as you mentioned below (thanks for the details) if it turns out to be useful. Got a patch? [details left for linux-audit folks] > Consider that: > > 1. Every other UID is handled by system calls: >getuid, setuid, geteuid, setreuid, >setresuid, getresuid, setfsuid > > 2. HP's Tru64 has getluid() and setluid() system calls >that Linux should be compatible with. SecureWare has a >version too, which looks more-or-less compatible with >what HP is offering. (the descriptions do not conflict, >but one has more details) It looks like ssh, apache, >and sendmail (huh?) already knows to use these system >calls even. > > The header is used. Prototypes are the obvious. > The setuid() call returns 0 on success. > > Tru64 notes that the login UID is sometimes called the > audit UID (AUID) because it is recorded with most audit > events. > > getluid() returns an error if the LUID (AUID) is unset. > > SecureWare additionally notes that setuid() and setgid() will > also fail when the luid is unset, to ensure that the LUID > is set before any other identity changes. (probably Linux > should just disable setting LUID after that point) > > > > Just to be complete, here's what Sun did: > > Sun has getauid() and setauid() syscalls which are > somewhat similar. They take pointers to the ID, and they > require privilege (PRIV_SYS_AUDIT and PRIV_PROC_AUDIT > for setauid, or just PRIV_PROC_AUDIT for getauid) > These calls have been superceded by getaudit_addr() and > setaudit_addr(), which use structs containing: > > au_id_t ai_auid; // audit user ID > au_mask_t ai_mask; // preselection mask > au_tid_addr_t ai_termid; // terminal ID > au_asid_t ai_asid; // audit session ID > > (the terminal ID is variable length, containing a > network address and a length value for it) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] audit: handle loginuid through proc
On Thu, 2005-02-24 at 22:49 -0800, Chris Wright wrote: > * Albert Cahalan ([EMAIL PROTECTED]) wrote: > > Assuming you'd like ps to print the LUID, how about > > putting it with all the others? There are "Uid:" > > lines in the /proc/*/status files. > > It's also set (written) via /proc, so it should probably stay separate. Gross. Please rip this out before it hits the streets. (it's an interface change that might need eternal support) Consider that: 1. Every other UID is handled by system calls: getuid, setuid, geteuid, setreuid, setresuid, getresuid, setfsuid 2. HP's Tru64 has getluid() and setluid() system calls that Linux should be compatible with. SecureWare has a version too, which looks more-or-less compatible with what HP is offering. (the descriptions do not conflict, but one has more details) It looks like ssh, apache, and sendmail (huh?) already knows to use these system calls even. The header is used. Prototypes are the obvious. The setuid() call returns 0 on success. Tru64 notes that the login UID is sometimes called the audit UID (AUID) because it is recorded with most audit events. getluid() returns an error if the LUID (AUID) is unset. SecureWare additionally notes that setuid() and setgid() will also fail when the luid is unset, to ensure that the LUID is set before any other identity changes. (probably Linux should just disable setting LUID after that point) Just to be complete, here's what Sun did: Sun has getauid() and setauid() syscalls which are somewhat similar. They take pointers to the ID, and they require privilege (PRIV_SYS_AUDIT and PRIV_PROC_AUDIT for setauid, or just PRIV_PROC_AUDIT for getauid) These calls have been superceded by getaudit_addr() and setaudit_addr(), which use structs containing: au_id_t ai_auid; // audit user ID au_mask_t ai_mask; // preselection mask au_tid_addr_t ai_termid; // terminal ID au_asid_t ai_asid; // audit session ID (the terminal ID is variable length, containing a network address and a length value for it) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] audit: handle loginuid through proc
On Thu, 2005-02-24 at 22:49 -0800, Chris Wright wrote: * Albert Cahalan ([EMAIL PROTECTED]) wrote: Assuming you'd like ps to print the LUID, how about putting it with all the others? There are Uid: lines in the /proc/*/status files. It's also set (written) via /proc, so it should probably stay separate. Gross. Please rip this out before it hits the streets. (it's an interface change that might need eternal support) Consider that: 1. Every other UID is handled by system calls: getuid, setuid, geteuid, setreuid, setresuid, getresuid, setfsuid 2. HP's Tru64 has getluid() and setluid() system calls that Linux should be compatible with. SecureWare has a version too, which looks more-or-less compatible with what HP is offering. (the descriptions do not conflict, but one has more details) It looks like ssh, apache, and sendmail (huh?) already knows to use these system calls even. The prot.h header is used. Prototypes are the obvious. The setuid() call returns 0 on success. Tru64 notes that the login UID is sometimes called the audit UID (AUID) because it is recorded with most audit events. getluid() returns an error if the LUID (AUID) is unset. SecureWare additionally notes that setuid() and setgid() will also fail when the luid is unset, to ensure that the LUID is set before any other identity changes. (probably Linux should just disable setting LUID after that point) Just to be complete, here's what Sun did: Sun has getauid() and setauid() syscalls which are somewhat similar. They take pointers to the ID, and they require privilege (PRIV_SYS_AUDIT and PRIV_PROC_AUDIT for setauid, or just PRIV_PROC_AUDIT for getauid) These calls have been superceded by getaudit_addr() and setaudit_addr(), which use structs containing: au_id_t ai_auid; // audit user ID au_mask_t ai_mask; // preselection mask au_tid_addr_t ai_termid; // terminal ID au_asid_t ai_asid; // audit session ID (the terminal ID is variable length, containing a network address and a length value for it) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] audit: handle loginuid through proc
* Albert Cahalan ([EMAIL PROTECTED]) wrote: On Thu, 2005-02-24 at 22:49 -0800, Chris Wright wrote: * Albert Cahalan ([EMAIL PROTECTED]) wrote: Assuming you'd like ps to print the LUID, how about putting it with all the others? There are Uid: lines in the /proc/*/status files. It's also set (written) via /proc, so it should probably stay separate. Gross. Please rip this out before it hits the streets. (it's an interface change that might need eternal support) It's already supported via the new pam_loginuid module. Also the loginuid is not a part of the task proper, rather the audit context. It's treated in a manner similar to security contexts which are handled via /proc interfaces. Having said that, I wouldn't be opposed to a patch that promotes it to compatible syscall as you mentioned below (thanks for the details) if it turns out to be useful. Got a patch? [details left for linux-audit folks] Consider that: 1. Every other UID is handled by system calls: getuid, setuid, geteuid, setreuid, setresuid, getresuid, setfsuid 2. HP's Tru64 has getluid() and setluid() system calls that Linux should be compatible with. SecureWare has a version too, which looks more-or-less compatible with what HP is offering. (the descriptions do not conflict, but one has more details) It looks like ssh, apache, and sendmail (huh?) already knows to use these system calls even. The prot.h header is used. Prototypes are the obvious. The setuid() call returns 0 on success. Tru64 notes that the login UID is sometimes called the audit UID (AUID) because it is recorded with most audit events. getluid() returns an error if the LUID (AUID) is unset. SecureWare additionally notes that setuid() and setgid() will also fail when the luid is unset, to ensure that the LUID is set before any other identity changes. (probably Linux should just disable setting LUID after that point) Just to be complete, here's what Sun did: Sun has getauid() and setauid() syscalls which are somewhat similar. They take pointers to the ID, and they require privilege (PRIV_SYS_AUDIT and PRIV_PROC_AUDIT for setauid, or just PRIV_PROC_AUDIT for getauid) These calls have been superceded by getaudit_addr() and setaudit_addr(), which use structs containing: au_id_t ai_auid; // audit user ID au_mask_t ai_mask; // preselection mask au_tid_addr_t ai_termid; // terminal ID au_asid_t ai_asid; // audit session ID (the terminal ID is variable length, containing a network address and a length value for it) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] audit: handle loginuid through proc
* Albert Cahalan ([EMAIL PROTECTED]) wrote: > Assuming you'd like ps to print the LUID, how about > putting it with all the others? There are "Uid:" > lines in the /proc/*/status files. It's also set (written) via /proc, so it should probably stay separate. thanks, -chris -- Linux Security Modules http://lsm.immunix.org http://lsm.bkbits.net - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] audit: handle loginuid through proc
Assuming you'd like ps to print the LUID, how about putting it with all the others? There are "Uid:" lines in the /proc/*/status files. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] audit: handle loginuid through proc
Assuming you'd like ps to print the LUID, how about putting it with all the others? There are Uid: lines in the /proc/*/status files. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/