Re: [RFC] last(1) with security.bsd.see_other_uids support
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 directly, only 16 groups can be > queried. Therefore the daemon cannot check the process credential for > the groups but will have to check the group database for the user.) > > Also, the attack surface of such a daemon may be smaller than that of a > setuid/setgid program. > > Alternatively, the daemon could be a setgid program that is spawned by > the utmpx APIs when needed. I like this idea a lot. I will experiment with that. -- Regards, Bryan Drewery bdrewery@freenode, bryan@EFNet signature.asc Description: OpenPGP digital signature
Re: [RFC] last(1) with security.bsd.see_other_uids support
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 some input on code sharing. My goal is to > add this support to w(1) and who(1) as well. FWIW I have been running a > similar patch on my own shared-hosting systems (pre-utmpx) for a few years. > Changes: > * Added utmp group > * All utmpx files are 660 root:utmp The utmp group was previously (on other systems) used to allow applications write access to utmp without making them setuid root (making them setgid utmp instead). > * last(1) runs setgid(utmp) and drops this as soon as the utmpx files > are opened. > * Users in the wheel or utmp group can see all entries > * IFF security.bsd.see_other_uids=0: users only see their own entries, > as well as shutdown/boot/init times. > * If security.bsd.see_other_uids=1, all entries are always shown, as it > does now. > Justifications: > Why the changes? This makes sense for shared hosting environments where > jails are not practical. A user should be able to see their own login > history, to see if someone has been accessing their account, but not to > see the IPs of other users. The intention is *not* to disallow them to > see that other users of the system. Obviously they can just cat > /etc/passwd. This is just about IP privacy. > Why the setgid? Allow reading the entries, but disallow directly opening > the utx files. I've seen some shared hosts incorrectly chmod 0 > /usr/bin/last, but still leave the utmp files wide open for reading! > Why the utmp group? It's consistent with other systems (OpenBSD, Linux), > and allows giving a user access to see all entries, without granting > them wheel or allowing a non-privileged user to run as setgid(wheel). It > also helps mitigates security concerns by using a specific group only > having extra privilege to utmpx files. > I originally had not planned for security.bsd.see_other_uids, but > considering POLA and consistency, it makes sense. This requires every utmpx access to go through a setgid binary, regardless of the value of security.bsd.see_other_uids. If called by a user that is not root or in the utmp group, getutxent(3) and related APIs become worthless. While POSIX permits this (security restriction denying all visibility of utmpx), this is not what applications expect. For example, tcsh and zsh offer a "watch" feature that reports on logins and logouts by calling utmpx APIs. 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 directly, only 16 groups can be queried. Therefore the daemon cannot check the process credential for the groups but will have to check the group database for the user.) Also, the attack surface of such a daemon may be smaller than that of a setuid/setgid program. Alternatively, the daemon could be a setgid program that is spawned by the utmpx APIs when needed. -- Jilles Tjoelker ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: reverse USB driver - is it possible?
On Tue, Jun 05, 2012 at 09:31:38AM -0500, Mark Felder wrote: > On Mon, 04 Jun 2012 18:51:50 -0500, Daniel O'Connor > wrote: > > >ISTR someone on the lists was talking about a device by http://i-odd.com > >which does what you want. > >I found http://renosite.com/ which is a home brew version of the same > >basic idea. > > Zalman ZM-VE200 and ZM-VE300 are also what you want. Kind of nice to have > ISOs on a drive and be able to make it fake a CDROM/DVDROM/BDROM at your > leisure. Recently got a ZM-VE300, based on such advice. I'm new to it, but I had one instance of a desktop ditsro live CD fail because it perceived the faked CD-ROM device to have timed out. Just one data point. > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" -- Brian Reichert BSD admin/developer at large ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: reverse USB driver - is it possible?
On Mon, 04 Jun 2012 18:51:50 -0500, Daniel O'Connor wrote: ISTR someone on the lists was talking about a device by http://i-odd.com which does what you want. I found http://renosite.com/ which is a home brew version of the same basic idea. Zalman ZM-VE200 and ZM-VE300 are also what you want. Kind of nice to have ISOs on a drive and be able to make it fake a CDROM/DVDROM/BDROM at your leisure. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] last(1) with security.bsd.see_other_uids support
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 cover all sorts of "this
> uses TTYs" scenarios. It wouldn't amaze me if even irssi has setuid
> utmp on some systems, simply because it runs on a TTY. Also, there's
> no need for consistency. This group name would only be used by the C
> library to apply ownership, the log rotator and some of our tools.
>
Yeah I considered naming it utx or utmpx. It doesn't matter to me really.
> Still, I wonder whether it's worth the effort. In its current form,
> you can simply chmod 0600 the utx.* files to hide the information
> inside to non-administrative users. I guess you can essentially decide
> to make any tool setuid, simply because it can print things referring
> to a user. For example, why not have a tool that allows regular users
> to view their own auth.log entries?
Yes. It's worth the effort because I am willing and able to work on it
and as a shared hosting provider, I am constantly asked for access to
this information. It makes sense to provide users access to their own data.
I also plan to expand similar effort elsewhere.
>
>> @@ -212,7 +255,30 @@ struct idtab {
>>/* Load the last entries from the file. */
>>if (setutxdb(UTXDB_LOG, file) != 0)
>>err(1, "%s", file);
>> +
>> + /* drop setgid now that the db is open */
>> + setgid(getgid());
>> +
>> + /* Lookup current user information */
>> + pw = getpwuid(getuid());
>> +
>> + len = sizeof(see_other_uids);
>> + if (sysctlbyname("security.bsd.see_other_uids", &see_other_uids,
>> &len,
>> NULL, 0))
>> + see_other_uids = 0;
>> + restricted = is_user_restricted(pw, see_other_uids);
>> +
>>while ((ut = getutxent()) != NULL) {
>> + /* Skip this entry if the invoking user is not permitted
>> +* to see it */
>> + if (restricted &&
>> + !(ut->ut_type == BOOT_TIME ||
>> + ut->ut_type == SHUTDOWN_TIME ||
>> + ut->ut_type == OLD_TIME ||
>> + ut->ut_type == NEW_TIME ||
>> + ut->ut_type == INIT_PROCESS) &&
>> + strncmp(ut->ut_user, pw->pw_name,
>> sizeof(ut->ut_user)))
>> + continue;
>> +
>>if (amount % 128 == 0) {
>>buf = realloc(buf, (amount + 128) * sizeof *ut);
>>if (buf == NULL)
>>
>
> Though not a common case, this code will not work properly when
> multiple users share the same uid. Consider comparing against the
> username of the logged in user (see getlogin(2)), or resolving the uid
> for each entry and comparing the uids.
Good find.
>
> Best regards,
Thanks for the input!
--
Regards,
Bryan Drewery
bdrewery@freenode, bryan@EFNet
signature.asc
Description: OpenPGP digital signature
Re: SuperPages utilization survey
On Sat, 02 Jun 2012 06:49:18 -0500, Florian Smeets wrote: As far as i understand it does at least enable usage of pages up to 4MB, perhaps someone should teach mysql about the FreeBSD's limits? If you look at the output i sent, it certainly changes from using no superpage mappings at all to using them to some degree, if you script can be trusted Wow, this is a nice find. If someone were to add a patch for FreeBSD's superpages we might be able to get a nice little performance boost with little effort. Even the increase to 4MB for now is a welcome improvement. I'll make sure to put this in my toolbox ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] last(1) with security.bsd.see_other_uids support
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 amaze me if even irssi has setuid
utmp on some systems, simply because it runs on a TTY. Also, there's
no need for consistency. This group name would only be used by the C
library to apply ownership, the log rotator and some of our tools.
Still, I wonder whether it's worth the effort. In its current form,
you can simply chmod 0600 the utx.* files to hide the information
inside to non-administrative users. I guess you can essentially decide
to make any tool setuid, simply because it can print things referring
to a user. For example, why not have a tool that allows regular users
to view their own auth.log entries?
> @@ -212,7 +255,30 @@ struct idtab {
> /* Load the last entries from the file. */
> if (setutxdb(UTXDB_LOG, file) != 0)
> err(1, "%s", file);
> +
> + /* drop setgid now that the db is open */
> + setgid(getgid());
> +
> + /* Lookup current user information */
> + pw = getpwuid(getuid());
> +
> + len = sizeof(see_other_uids);
> + if (sysctlbyname("security.bsd.see_other_uids", &see_other_uids, &len,
> NULL, 0))
> + see_other_uids = 0;
> + restricted = is_user_restricted(pw, see_other_uids);
> +
> while ((ut = getutxent()) != NULL) {
> + /* Skip this entry if the invoking user is not permitted
> + * to see it */
> + if (restricted &&
> + !(ut->ut_type == BOOT_TIME ||
> + ut->ut_type == SHUTDOWN_TIME ||
> + ut->ut_type == OLD_TIME ||
> + ut->ut_type == NEW_TIME ||
> + ut->ut_type == INIT_PROCESS) &&
> + strncmp(ut->ut_user, pw->pw_name,
> sizeof(ut->ut_user)))
> + continue;
> +
> if (amount % 128 == 0) {
> buf = realloc(buf, (amount + 128) * sizeof *ut);
> if (buf == NULL)
>
Though not a common case, this code will not work properly when
multiple users share the same uid. Consider comparing against the
username of the logged in user (see getlogin(2)), or resolving the uid
for each entry and comparing the uids.
Best regards,
--
Ed Schouten
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
