Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-07 Thread Ed Schouten
2012/6/6 Pawel Jakub Dawidek : > Any privileged daemon is much bigger threat. Also, do we really want a > daemon running all the time just to be able to parse utx files? Well, if you think of it, it's not a very strange idea: - You can simply get rid of /var/run/utx.active. There's no need for th

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-07 Thread Ed Schouten
2012/6/5 Jilles Tjoelker : > To avoid this, the utmpx APIs could communicate with a privileged daemon > if the files are not readable. The daemon can check the identity of the > caller via getpeereid(3). +1. I would really like to have something like this. Another advantage of this approach would

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-06 Thread Jilles Tjoelker
On Wed, Jun 06, 2012 at 01:20:12PM +0200, Pawel Jakub Dawidek wrote: > On Tue, Jun 05, 2012 at 11:31:01PM +0200, Jilles Tjoelker wrote: > > Also, the attack surface of such a daemon may be smaller than that of a > > setuid/setgid program. > Really? I don't see that. With current patch and setgid t

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-06 Thread Pawel Jakub Dawidek
On Tue, Jun 05, 2012 at 11:31:01PM +0200, Jilles Tjoelker wrote: > Also, the attack surface of such a daemon may be smaller than that of a > setuid/setgid program. Really? I don't see that. With current patch and setgid to utmp the process can only read some files that don't even contain very sens

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-05 Thread Bryan Drewery
On 6/5/2012 4:31 PM, Jilles Tjoelker wrote: > To avoid this, the utmpx APIs could communicate with a privileged daemon > if the files are not readable. The daemon can check the identity of the > caller via getpeereid(3). (Unfortunately, even if getpeereid() is > bypassed and LOCAL_PEERCRED called d

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-05 Thread Jilles Tjoelker
On Sun, Jun 03, 2012 at 08:42:04PM -0500, Bryan Drewery wrote: > I've written up a patch to add some privacy to last(1) while still > giving non-privileged users access to their own login history. > This is still a work in progress. I am reaching out to make sure my > approach is proper and to get

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-05 Thread Bryan Drewery
On 6/5/2012 9:06 AM, Ed Schouten wrote: > Hi Bryan, > > 2012/6/4 Bryan Drewery : >> * Added utmp group > > Why call it utmp? FreeBSD 9+ does not do utmp. It does utmpx. Also, > too many pieces of software already abuse the group `utmp'. Instead of > doing utmp handling with it, it is used to cove

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-05 Thread Ed Schouten
Hi Bryan, 2012/6/4 Bryan Drewery : > * Added utmp group Why call it utmp? FreeBSD 9+ does not do utmp. It does utmpx. Also, too many pieces of software already abuse the group `utmp'. Instead of doing utmp handling with it, it is used to cover all sorts of "this uses TTYs" scenarios. It wouldn't

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-04 Thread Bryan Drewery
On 6/4/2012 8:17 AM, Bryan Drewery wrote: > > > On 6/4/2012 4:42 AM, Pawel Jakub Dawidek wrote: >> A library is definiately a better place, although then I wouldn't pass >> see_other_uids as an argument, but obtain it within the function itself. > > Does libc make sense for this? I'm thinking ye

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-04 Thread Wojciech Puchar
Justifications: Why the changes? This makes sense for shared hosting environments where jails are not practical. jails are NEVER practical, it is only a necessity! Necessity to be able to run stupid software that cannot conform to basic unix standards and require to be run as root or from ro

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-04 Thread Bryan Drewery
On 6/4/2012 4:42 AM, Pawel Jakub Dawidek wrote: > A library is definiately a better place, although then I wouldn't pass > see_other_uids as an argument, but obtain it within the function itself. Does libc make sense for this? I'm thinking yes since it's where the utx functions live. In particu

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-04 Thread Bryan Drewery
On 6/4/2012 4:42 AM, Pawel Jakub Dawidek wrote: > On Sun, Jun 03, 2012 at 08:42:04PM -0500, Bryan Drewery wrote: >> Questions: >> >> To add this support to w(1) and who(1), I want to share the >> is_user_restricted() function among all 3 binaries. I don't think this >> really belongs in libc/libu

Re: [RFC] last(1) with security.bsd.see_other_uids support

2012-06-04 Thread Pawel Jakub Dawidek
On Sun, Jun 03, 2012 at 08:42:04PM -0500, Bryan Drewery wrote: > Hi, > > I've written up a patch to add some privacy to last(1) while still > giving non-privileged users access to their own login history. > > This is still a work in progress. I am reaching out to make sure my > approach is proper

[RFC] last(1) with security.bsd.see_other_uids support

2012-06-03 Thread Bryan Drewery
Hi, I've written up a patch to add some privacy to last(1) while still giving non-privileged users access to their own login history. This is still a work in progress. I am reaching out to make sure my approach is proper and to get some input on code sharing. My goal is to add this support to w(1